Bitte wirf einen Blick auf die FAQ ( Englisch, Deutsch oder Französisch) auf der Projekt Homepage.
Wenn du einen HTTP Proxy Server für den Zugriff auf das Internet benutzen musst und du möchtest, dass die GUI diesen Proxy benutzt, um Serverlisten über HTTP zu holen, musst du die Umgebungsvariable 'http_proxy' setzen, bevor du die GUI startest (=Befehlszeile):
export http_proxy=http://wwwcache.somehost.net:8080/
Beachte den Slash '/' am Ende. Andere Programme wie wget und lynx werden diese
Einstellung auch benutzen. Um zu prüfen, ob die Variable gesetzt ist kannst du mit
echo $http_proxy prüfen.
Das Beste ist wahrscheinlich die export-Zeile ans Ende deiner ~/.bashrc Datei anzufügen, dann musst du das nicht jedesmal eintippen, wenn du die GUI startest. Die Umgebungsvariable 'http_proxy' wird dann jedesmal, wenn du dich anmeldest automatisch gesetzt.
Das bedeutet, dass nachdem ein Teil einer Datei heruntergeladen wurde die Checksumme (Teil-Hash) dieses Teils der Datei auf deiner Festplatte nicht mit der Checksumme übereinstimmt, die der Teil haben sollte.
Darüber muss man sich keine Gedanken machen. eDonkey/Overnet hat das Problem bemerkt und wird diesen Teil erneut herunterladen.
Übertragungsfehler passieren eben. Dagegen kann man nichts machen. Mach dir keinen Kopf. Falls das aber mit verschiedenen Dateien sehr, sehr oft passiert ist es möglich, dass es irgendein Hardwareproblem gibt (RAM/Festplatte/Controller/Kabel fehlerhaft, Overclocking, Überhitzung des Systems, Dateisystemprobleme usw) .
Die GUI sucht auf deinem System nach einem Browser und wird den ersten, den sie findet benutzen (Galeon, Konqueror, Mozilla, Netscape, Opera). Wenn du einen bestimmten Browser bevorzugst, solltest du die Umgebungsvariable 'BROWSER' in der Befehlszeile setzen bevor du die GUI startest:
export BROWSER=/usr/bin/konqueror
Du musst den absoluten Pfad des Programms angeben. Diesen Pfad erhältst du entweder mit
whereis konqueror oder which konqueror (Anmerkung:
which findet die Programme vielleicht nicht immer, weil Pfade fest vorgegeben sind).
Das Beste ist wahrscheinlich die export-Zeile ans Ende deiner ~/.bashrc Datei anzufügen, dann musst du das nicht jedesmal eintippen, wenn du die GUI startest. Die Umgebungsvariable 'BROWSER' wird dann jedesmal, wenn du dich anmeldest automatisch gesetzt.
Mit der neuesten GUI Version kannst du laufende Downloads ansehen, bevor sie komplett sind, wenn der Core auf deinem lokalen System läuft und wenn dein Core die Namen der temporären Dateien (x.part) mitteilt. Alle aktuellen Versionen des Core sollten das machen.
Wenn du die Vorschaufunktion zum ersten Mal benutzt, schreibt die GUI ein Standardskript
auf deine Festplatte. Dieses Vorschauskript heisst ~/.ed2k_gui/ed2k_gui_preview.
Diese Datei kann mit einem Texteditor nach deinen Bedürfnissen angepasst werden.
Und so funktioniert das: Die GUI ruft das Skript auf und übergibt den Pfad der teilweise heruntergeladenen
Datei als Parameter. Dieser erscheint im Skript als $* (was soviel bedeutet wie:
'mit allen erhaltenen Parametern ersetzen'). Die GUI wird auch eine Umgebungsvariable
ED2K_PREVIEW_EXTENSION auf die Dateierweiterung in Kleinbuchstaben setzen
(weil man mit einem Namen wie /mnt/temp/34.part den Dateityp nicht kennt).
Jetzt vergleicht das Skript die Dateierweiterung mit den eingetragenen Werten im case-Teil
des Skripts. Gibt es eine Übereinstimmung wird der Name zum abspielen der Datei in der Variable
PREVIEW_BIN mit jeglichen Parametern für das Programm gespeichert.
Danach wird das Programm gestartet.
Wie du siehst ist es kinderleicht dein Lieblingsprogramm einzustellen oder neue Dateitypen hinzuzufügen.
Nachdem das Programm beendet ist musst du auf Enter drücken, um das xterm Fenster, das geöffnet wurde, um die Ausgaben des Programms anzuzeigen, zu schliessen (somit kann das Abspielen auch mit Strc+c unterbrochen werden, z.B. für mpg123/ogg123).
Wenn du nicht möchtest, dass das Skript wartet nachdem das Programm beendet wurde, entfernst du einfach folgende zwei Zeilen aus dem Skript:
echo "Finished. Hit <enter> to close this window"
read
Wenn du möchtest, dass das xterm Fenster gleich nach dem Aufruf des Programms geschlossen wird entferne einfach die beiden Zeilen von oben und ändere die Zeile, in der das Programm augerufen wird in:
$PREVIEW_BIN "$*" &
Bitte schau dir den Abschnitt über ed2k-links im Kapitel Anwendung an.
TODO, see FAQ
Wenn das in Dateinamen oder Servernamen passiert, dann wahrscheinlich wegen deiner Spracheinstellung. Du musst rausfinden, wie du die Spracheinstellung auf etwas passendes setzt. Wenn du die Spracheinstellung aber änderst, dann benutze auf jeden Fall den UTF8 Zeichensatz und nicht ISO-8859-X (z.B. de_DE.UTF8).
Wie auch immer, eDonkey2000 und Overnet teilen der GUI oder anderen Clients nicht mit, mit welchem Zeichensatz ein String codiert ist. Also wirst du Dateinamen bei den Suchergebnissen nie genau so sehen, wie jemand anders mit einer anderen Spracheinstellung. Das sollte aber normalerweise kein großes Problem sein.
TODO, see FAQ
Warum? Keine Ahnung. Wahrscheinlich ein GTK+ Bug. Bei den Optionen kannst du die 'Doppelklicks in den Listen deaktivieren'. Das sollte das Problem beheben.
Wenn die Vorschaufunktion im Rechtsklick Menü in der Downloadliste ausgegraut ist gibt es dafür zwei Gründe:
(1) es ist keine Reihe ausgewählt
(2) die GUI denkt, das der Core auf einem anderen Computer läuft. Das ist der Fall, wenn du einen anderen Hostnamen als 'localhost' oder '127.0.0.1' angibst. (Anmerkung: wegen Anfragen von Benutzern ist eine ausgeklügeltere Erkennung des Hostnamens verworfen worden. Also ist zur Zeit alles bis auf 127.0.0.1 oder localhost nicht lokal.)
Problem: Dein Router kann eine Portnummer nur an genau eine IP Adresse weiterleiten.
Lösung: Betreibe alle Donkey Cores auf unterschiedlichen Ports (z.B. einen mit 3662, einen mit 4662, einen mit 5662 usw), und lasse deinen Router den entsprechenden Port zur passenden IP weiterleiten. Anmerkung: Es muss für jeden Core nur ein TCP Port weitergeleitet werden, um eine hohe ID zu erhalten.
Möglicherweise laufen mehrere Cores und du willst sie entweder gleichzeitig oder zu unterschiedlichen mit einer GUI verbinden. In diesem Fall wirst du wahrscheinlich die '-n' Befehlszeilenoption der GUI benutzen wollen, was die GUI in einer anderen 'Instanz' startet. Das bedeutet, dass ein anderer Satz Konfigurationsdateien benutzt wird. Für den ersten Core startest du die GUI ganz normal. Für den zweiten Core übergibst du die Option '-n 2' an die GUI. Damit werden deine Statistiken usw getrennt behandelt. Du kannst die GUI beim starten auch automatisch zum entsprechenden Core verbinden lassen.
Das ist ein Problem. Ein Core kann immer nur mit einer GUI verbunden sein.
Es gibt aber eine einfache und freie Lösung dafür: VNC.
Installiere einen VNC Server auf dem Rechner, auf dem der Core läuft und VNC Clients (gibts für alle Plattformen) auf den Rechnern, von denen du die GUI und den Core kontrollieren willst. Jetzt startest du die GUI auf dem Rechner, auf dem der Core läuft und kontrollierst die GUI über VNC. Ein VNC Desktop kann von mehreren Usern genutzt werden, also sollte dieses Problem gelöst sein. Wenigstens theoretisch, da ich es noch nicht selbst probiert habe.
Das ist mein (Thomas) Startskript for eDonkey. Ich hatte keine Lust jeden Tag in das richtige Verzeichnis zu wechseln... Es holt eine neue Serverliste, startet den Core, wartet und startet dann die GUI.
#!/bin/sh # eDonkey2000 Startskript # Den Donkey in seinem Heimatverzeichnis starten, ersetz das mit deinem eDonkey Verzeichnis! cd ~/edonkey # Serverliste holen (wir versuchen clever zu sein) mv server.met _server.met wget http://ocbmaurice.dyndns.org/pl/slist.pl/server.met?download/server-max.met || cp _server.met server.met rm _server.met # eDonkey in einer benannten screen-Session starten (Du brauchst GNU screen!) screen -dmS donkey -- ./donkey - ! # Alternative: # ./donkey - ! & # Ein wenig warten... sleep 5 # Die GUI starten ed2k_gui -c
Normalerweise kannst du Programme in der Shell mit einem '&' am Ende starten und sie werden im Hintergrund laufen. Leider funktioniert das mit dem eDonkey nicht richtig. Ähnliche Probleme gibt es auch, wenn du denn Donkey über telnet/ssh (ssh ist natürlich zu bevorzugen!) starten willst. Natürlich soll der Core weiterlaufen, wenn du dich abmeldest. 'nohup' funtioniert leider mit dem Donkey auf vielen Systemen nicht.
Für solche Zaubereien brauchst du das 'screen' Tool, das wahrscheinlich schon auf deinem System installiert
ist. Lies das Manual mit man screen>. Hier ist eine Zusammenfassung:
Startw den Donkey mit
cd /home/joe/ed2k/
screen -dmS donk ./donkey0.50.1 - !
Das 'cd /home/joe/ed2k' stellt sicher, dass der Core seine Konfigurationsdateien immer im selben Verzeichnis liest und schreibt. Wenn du das nicht machst, wird der Core diese Dateien in das aktuelle Arbeitsverzeichnis schreiben, was wahrscheinlich irgendwann Probleme bereitet.
Die Option '-' lässt den Core nach einer GUI horchen und die Option '!' lässt den Core nur Anweisungen von der GUI annehmen, nicht aber von der Befehlszeile. Das wird benötigt, um den Core korrekt aus der GUI zu beenden.
screen verlässt du, indem du zuerst Strg-a, dann Strg-d drückst. Jetzt solltest du wieder in der Shell sein.
Du kannst den Donkey jederzeit mit
screen -d -r donk
zurückholen.
Das kann verschiedene Gründe haben. Das mit der Firewall darf man nicht so wörtlich nehmen. 'Firewalled' beudeutet nur, dass sich ein Server nicht erfolgreich über den eingestellten Port (normalerweise 4662) mit dem Core verbinden konnte.
Natürlich ist eine Möglichkeit dafür, dass du wirklich hinter einer Firewall bist. Entweder läuft diese auf deinem Computer oder auf deinem Gateway/Router und blockiert den ankommenden Verbindungsversuch von dem Server.
Eine andere Möglichkeit ist, dass du einen DSL Router oder etwas ähnliches verwendest und dieser NAT (= Network Address Translation = IP Masquerading = Internet Connection Sharing/ICS) ausführt. NAT wird benutzt, damit mehrere Computer eines kleinen Netzwerk sich eine Internetverbindung teilen können In diesem Fall wird deinem Router die 'öffentliche IP' von deinem ISP (Internet Service Provider) zugewiesen, und alle Computer im LAN (Local Area Network) haben eine 'private IP' (z.B. 192.168.x.x oder 10.x.x.x). In diesem Fall musst du Portweiterleitung auf dem Router einrichten. Der TCP Port 4662 muss zu dem Computer mit dem Core weitergeleitet werden. Wenn in deinem Netzwerk mehrere Donkeys laufen, musst du sie alle auf unterschiedlichen Ports betreiben und jeden dieser Ports zur entsprechenden IP weiterleiten lassen.
Ausserdem gibt es einige falsch eingerichtete Server, die keine abgehenden Verbindungen zu 'exotischen' Ports erlauben (also andere als 4662). Diese Server werden dir sagen du wärst 'firewalled', obwohl sie es selbst sind. Das wird wahrscheinlich gelegentlich passieren, wenn du einen anderen Port als TCP 4662 benutzt.Falls aber wirklich alle Server behaupten du wärst 'firewalled', ist das kein sehr wahrscheinlicher Grund dafür.
Leider Unterstützt er wirklich keine SOCKS Proxy Server, aber du könntest tsocks probieren, was SOCKS Proxy Unterstützung für Programme bereitstellt, die das eigentlich nicht unterstützen. (Das funktioniert über ein Library, die Network System Calls nach connect() abfängt und sie zu einem SOCKS Proxy weiterleitet)
Deine Internetverbindung wird, nachdem eDonkey eine Weile läuft schrecklich langsam oder träge (der Verbindungsaufbau zu einem Webserver oder das Abrufen deiner eMails dauert plötzlich einige Sekunden statt Millisekunden)
Vorneweg: wenn das Problem mit bestimmten Servern unabhägig davon, ob eDonkey läuft oder nicht, reproduziert werden kann liegt das Problem woanders. Falls du PPPoE (PPP-over-Ethernet) benutzt solltest du beispielsweise die MTU Einstellungen deines Netzwerkgerätes (pppX oder ethX) überprüfen. Falls das Problem nur auftritt, wenn eDonkey viel uploaded: lies weiter.
Hier eine kleine Zusammenfassung des Problems: dein DSL Router hat eine eingebaute Warteschlange für Pakete, die ziemlich einfach arbeitet: Das zuerst ankommende Paket geht auch zuerst wieder raus (FIFO = first in first out). Wenn die Warteschlange deines Routers voll ist, werden einfach Pakete "weggeworfen". Das ist ein ganz normaler Vorgang und das TCP Protokoll kümmert sich darum. Das Problem besteht darin, dass für jedes empfangene Paket eine kleine Bestätigung gesendet werden muss (ACK = acknowledgement), damit der Absender sicher sein kann, dass das Paket angekommen ist. Dieser Mechanismus wird benutzt, um verlorengegangene Pakete auszugleichen und die Übertragungsgeschwindigkeit an die verfügbare Bandbreite anzupassen. Wenn die Warteschlange deines Router wegen dem Upload von eDonkey voll ist und du dich mit einem Webserver verbinden willst, wird die Verbindungsanfrage (SYN) zum Router geschickt, der sie einreiht. Wenn die Warteschlange aber voll ist wird es einige Sekunden dauern, bis das SYN Paket tatsächlich zum Webserver gesendet wird, weil der Router normalerweise nicht zwischen wichtigen und unwichtigen Paketen unterscheiden kann. Das gleiche wiederholt sich für jedes weitere Paket, das du sendest (z.B. eine HTTP-GET Anfrage deines Webbrowsers). Darum wird die Sache dann träge. Du musst bedenken, dass auch wenn deine Verbindungsgeschwindigkeit für den Upload technisch gesehen z.B. 128kbps (16 kB/s) ist, wird doch ein Teil davon durch die Header der unterschiedlichen beteiligten Protokolle verbraucht. Also ist die effektive Geschwindigkeit niedriger und deine Uploadgeschwindigkeit kann leicht ausgereizt werden, auch wenn die eingestellten Werte unter dieser Grenze liegen.
Was tun?
Ganz einfach: du möchtest Quality-of-Service (QoS). Neuere 2.4.x Linux Kernel haben das schon dabei, du musst nur sicherstellen, dass dein Kernel mit voller QoS Unterstützung kompiliert ist (als Modul oder fest eingebaut).
Das Prinzip ist einfach: wir stellen sicher, dass die Paketwarteschlange des Router nie voll wird. Um das zu erreichen werden die Pakete nicht mehr auf dem Router, sondern auf deinem Linuxrechner in die Warteschlange gestellt. (Anmerkung: normalerweise passiert das nicht, weil die Verbindung von deinem Rechner zum Router sehr viel schneller als die Verbindung zum Internet ist, so dass der Linux Kernel im Normalfall einfach alles ohne Verzögerung zum Router schicken wird). Da jetzt die Warteschlange von deinem Linux Kernel verwaltet wird kannst du alle möglichen schönen Dinge damit machen. Zum Beispiel können einige Pakete Vorrang vor anderen erhalten. Diese Pakete werden dann das Warten 'überspringen' und sofort gesendet, auch wenn andere (weniger wichtige) Pakete warten. Ich persönlich gebe dem Verkehr auf den 'interaktiven' Ports (21, 22, 23 und 110 aber nicht 80, weil viele Windowsbenutzer ihren Donkey diesen Port benutzen lassen), dem Verkehr zu meinen 'Lieblingswebseiten' und allen 'kleinen Pakete' (normalerweise SYN und ACK) die höchste Priorität.
Eine gute Beschreibung davon gibt es hier von Emmanuel Roger: http://www.prout.be/qos/QoS-connection-tuning-HOWTO.html.
Aus meiner Erfahrung kann ich nur raten die Finger von anderen HOWTOs (wie das ADSL-Bandwidth-Management-HOWTO), zu lassen. Es sei denn du suchst eine Herausforderung. Dieses und die meisten anderen HOWTOs, die ich dazu gefunden habe, erfordern es die Kernel-Quellen und die ipables-Quellen zu patchen, was sich als besonders schwierig erweist, wenn die dort erwähnten Patches nicht mit den neuesten Kernel und iptables Releases funktionieren...
Hier ist ein Ausschnit aus meinem iptables start-up script, falls es jemanden interessiert:
##########################################################
#
# Quality of Service (QoS)
#
# from http://www.prout.be/qos/QoS-connection-tuning-HOWTO-4.html
#
##########################################################
# reset
tc qdisc del dev eth1 root 2>/dev/null > /dev/null
# mark packets with size 0-500 (considered interactive traffic)
#
iptables -t mangle -A OUTPUT -m length --length 0:500 -j MARK --set-mark 3
# mark UDP packets as important as well
#
iptables -t mangle -A OUTPUT -p udp -j MARK --set-mark 3
# bigger packets will be marked data traffic
#
iptables -t mangle -A OUTPUT -m length --length 500:1500 -j MARK --set-mark 4
# mark ssh/smtp/pop3 packets also as priority
# (not http, due to many donkey people using port 80)
for i in 22 25 110
do
iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp --dport "$i" -j TOS --set-tos Minimize-Delay
done
# mark favourite sites high priority traffic.
#
# slashdot(new) slashdot.org, www.ct.heise.de,
# edonkey2000, jigle.com, jabber.org
# google
#
for i in "66.35.250.150" "64.28.67.150" "193.99.144.71" \
"198.77.34.120" "212.249.10.246" "208.245.212.108" \
"216.239.39.101"
do
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.255" -j TOS --set-tos Minimize-Delay
done
# mark whole subdomains important
#
# amazon/imdb - sourceforge.net
#
for i in "207.171.166.0" "216.136.171.201"
do
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j MARK --set-mark 3
iptables -t mangle -A OUTPUT -p tcp -d "$i/255.255.255.0" -j TOS --set-tos Minimize-Delay
done
# create root cvq qdisc for our device eth1
#
tc qdisc add dev eth1 root handle 10: cbq bandwidth 10Mbit avpkt 1000 mpu 64
# DL bandwidth = 576 kbits
# UL bandwidth = 288 kbits
#
# Interactive class rate = DL bandwidth / 20 = 29
# Data class rate = UL bandwidth - Interactive class rate = 259
#
# Let's make the latter a bit smaller just to be on the safe side
# (we don't want a single packet ever to be queued on the router)
# => 190, which is much lower than suggested, but works best wor me
#
# (1500 is interface MTU?)
#
tc class add dev eth1 parent 10:0 classid 10:1 cbq bandwidth 10Mbit \
rate 29Kbit allot 1500 prio 1 maxburst 10 avpkt 100 isolated weight 100
tc class add dev eth1 parent 10:0 classid 10:2 cbq bandwidth 10Mbit \
rate 190Kbit allot 1500 prio 8 maxburst 2 avpkt 1500 bounded weight 1500
# tell kernel which class we want to send packets to
tc filter add dev eth1 parent 10:0 protocol ip handle 3 fw flowid 10:1
tc filter add dev eth1 parent 10:0 protocol ip handle 4 fw flowid 10:2
Das scheint mit neueren Cores zu passieren. Die wahrscheinlichste Ursache ist, dass eDonkey/Overnet mehr sogenannte 'file descriptors' (ein 'file descriptor' für jede öffene Datei und Netzwerkverbindung) benutzt, als dir als normaler Benutzer auf deinem System erlaubt sind.
Wie viele 'file descriptors' dir als Benutzer erlaubt sind, kannst du mit
%ulimit -n
prüfen. Dieser Wert ist für alle laufenden Programme und Prozesse.
Diese Grenze kann als root in der Datei /etc/security/limits.conf durch Anhängen einer Zeile wie der Folgenden geändert werden:
tim hard nofile 4096
'tim' ist der Benutzername, 'hard' steht für 'hard limit', 'nofile' steht für die Zahl der erlaubten 'file descriptors' und 4096 ist der Wert. Du kannst auch eine größere Zahl angeben, aber 4096 sollte ausreichen.
Jetzt mußt du dich noch um eine Sache kümmern, und das könnte sich von Distribution zu Distribution
unterscheiden. Wenn es die Datei /etc/pam.d/common-session gibt, dann sollte folgende Zeile
enthalten sein:
session required pam_limits.so
/etc/pam.d/login hinzufügen oder auskommentieren.
Wenn du gdm/kdm/xdm zum einloggen benutzt, solltest du /etc/pam.d/gdm, /etc/pam.d/kdm oder
/etc/pam.d/xdm diese Zeile hinzufügen.
Nach dem Bearbeiten dieser Datei musst du dich noch einmal 'richtig' anmelden (Abmelden von X und erneutes Anmelden an der Konsole oder xdm/kdm/gdm). Wenn du danach 'ulimit -n' in einem xterm ausführst, sollte der neue Wert ausgegeben werden und das Problem behoben sein.
Das genaue Vorgehen könnte von deinem System / deiner Distribution abhängen. Lass es mich bitte wissen, falls das Vorgehen auf deinem System anders ist.
Zuallererst: Hast du die '-' Option beim starten des Cores benutzt? Die '-' Option lässt den Core auf dem angegebenen aport nach einer GUI horchen. Wenn die Option nicht übergeben wird kann die GUI keine Verbindung zum Core herstellen. Deswegen sucht die GUI nur nach einem Core der mit der Option gestartet wurde.
Zweistens erwartet die GUI, dass der Core 'donkey*', 'overnet*', oder 'cdonkey*' heisst (nur der Anfang des Namens ist wichtig). Wenn du das Programm umbenannt hast, kann die GUI es nicht finden (wie sollte sie?).
Zwei einfache Lösungen: Entweder eine andere (nicht localhost) IP des Rechners nehmen, z.B. die IP der Netzwerkkarte (z.B. 192.168.0.2), oder eine Zeile zu /etc/hosts hinzufügen, z.B. 'core.outerspace.world 127.0.0.1' und 'core.outerspace.world' im Verbindungsdialog der GUI eintragen.
Weil die Entscheidung, auf einem lokal laufenden Core bei 'localhost' zu bestehen. absichtlich getroffen wurde ist es unwahrscheinlich, dass es geändert wird. Die Entscheidung wurde zugunsten des Durchschnittsbenutzer getroffen, um ihm den Einstieg zu erleichtern.
Anmerkung: die Erkennung eines laufenden Cores funktioniert momentan nur mit einem eingehängten /proc Dateisystem unter GNU/Linux Benutzer anderer Betriebssysteme (*BSD, MacOSX) können gerne einen Patch schicken, um das zu ändern :)
Prüfe, ob du ihn reproduzieren kannst und/oder wie er reproduziert werden kann.
Überprüfe, ob der Bug schon gemeldet wurde und, falls dem so ist, ob er schon gefixt wurde. Stell sicher, dass du alle Bugs siehst, sonst wirst du nur die offenen, nicht aber die schon geschlossenen Bugs zu Gesicht bekommen.
Wenn du weisst, wie man mit dem CVS umgeht, hol dir bitte die neueste Version der GUI aus dem CVS, um zu prüfen, ob es den Bug da auch noch gibt.
Übermittle den Bug mit dem Bug-Tracking System des Projekts mit so vielen Details wie möglich. Wenn du einen Sourceforge Account hast melde dich bitte an, damit ich im Falle weiterer Fragen auf dich zukommen kann. Eine andere Möglichkeit ist die 'monitor' ("Überwachungs-") Funktion oder von Zeit zu Zeit nachzuschauen, ob es weitere Fragen gibt.
Schreib mir eine eMail. Positives Feedback macht immer Freude :-)
Ausserdem habe ich jetzt einen amazon.co.uk Wunschzettel und einen amazon.de Wunschzettel falls du mir zum Dank für die Millionen Stunden Arbeit an der GUI eine Kleinigkeit schenken willst ;)