Installation eines sprechenden Desktop-Systems auf dem Raspberry Pi

Geschrieben von Steffen Schultz keine Kommentare
Kategorisiert in : Software Schlüsselwörter : A11Y, Linux, OpenSource, Orca, Raspberry Pi

Diese Anleitung zeigt, wie man einen Raspberry Pi zu einem sprechenden Desktop-System auf Basis von Raspbian Jessie und Mate aufrüstet. Der Mate-Desktop ist ein Fork des ehemaligen GNOME 2, und bietet in Sachen Geschwindigkeit und Zugänglichkeit derzeit den besten Kompromiss auf einem Raspberry Pi. Die folgenden Schritte orientieren sich stark an der englischen Anleitung auf Raspberryvi.org, sollen jedoch etwas kompakter verfasst sein, um unnötige Verwirrung zu minimieren. Grundkenntnisse im Bedienen eines Linux-Systems setze ich hier einfach mal voraus. :)

Vorbereitung

Damit der Raspberry Pi reibungslos per Sprachausgabe genutzt werden kann, wird eine USB-Soundkarte benötigt. Dies hat den Hintergrund, dass der Alsa-Treiber für den Soundchip des Pi nicht korrekt arbeitet, und in Zusammenarbeit mit der Sprachausgabe nur stotterndes Audio produziert oder sogar das System zum Absturz bringt. Als Soundkarte tut es in der Regel schon ein preisgünstiger USB-Dongle.
Des Weiteren wird die aktuellste Raspbian-Version benötigt, welche als Image in zwei Ausführungen von der offiziellen Download-Seite heruntergeladen werden kann. Am sinnvollsten ist die Nutzung des Lite-Images, da dieses ohne unnötigen Ballast auskommt, und dem Nutzer von Anfang an sämtliche Freiheiten beim Einrichten lässt. Via SSH-Zugriff kann Raspbian nach Belieben eingerichtet werden (Passwörter, Lokalisierung etc).

USB-Soundkarte einrichten

In der Regel sollten USB-Soundkarten bereits vom System erkannt werden, sobald sie eingesteckt wurden. Damit die USB-Soundkarte als Standardwiedergabe genutzt wird, editiert man die Datei /lib/modprobe.d/aliases.conf und sucht folgende Zeile:
options snd-usb-audio index=-2
Indem man dieser Zeile ein Kommentarzeichen "#" voranstellt, wird die USB-Soundkarte als "Device 0" eingerichtet, somit also als Standardsoundkarte.
Optional: Um die Ausgabe über HDMI und Audio-Ausgang des Pi komplett zu deaktivieren, kann in der Datei /boot/config.txt folgende Zeile auskommentiert werden:
dtparam=audio=on

Den Mate-Desktop installieren

Bevor die Desktop-Umgebung installiert wird, sollte man sich darüber im Klaren sein, dass der Raspberry Pi niemals einen vollwertigen Desktop-Rechner oder ein Notebook ersetzen kann. Selbst die Leistung des Raspi 3 gerät bei aufwändigen Anwendungen schnell mal an ihre Grenzen, frühere Pi-Versionen habe ich mit diesem Setup bislang nicht getestet. Man sollte also statt des kompletten Desktops lieber zunächst einen minimalen Desktop installieren, und hinterher entscheiden, welche Zusatzsoftware man tatsächlich benötigt. Folgende Pakete installieren die grundlegenden Mate-Komponenten sowie den Orca-Screenreader:
sudo apt update && sudo apt install mate-core mate-desktop-environment lightdm gnome-orca
Dieser Vorgang kann einige Stunden in Anspruch nehmen, je nach Geschwindigkeit der SDHC-Karte.

Accessibility-Switches

Die folgenden Befehle sorgen dafür, dass nach erfolgreicher Mate-Installation der Raspberry Pi beim nächsten Hochfahren sofort mit uns spricht:
dbus-launch gsettings set org.mate.interface accessibility true
dbus-launch gsettings set org.gnome.desktop.a11y.applications screen-reader-enabled true
Diese Befehle werden ohne sudo ausgeführt, um die Einstellungen für den angemeldeten Benutzer zu aktivieren. Um zu prüfen, ob alles geklappt hat, führt man Folgendes aus:
gsettings get org.mate.interface accessibility
gsettings get org.gnome.desktop.a11y.applications screen-reader-enabled
Beide Befehle sollten "true" als Rückmeldung ausgeben.

LightDM konfigurieren

LightDM ist der Display-Manager und ermöglicht die grafische Anmeldung am Desktop. Die Zugänglichkeitsoptionen müssen hier jedoch von Hand in die Konfigurationsdatei eingetragen werden. Hierzu editiert man die Datei /etc/lightdm/lightdm.conf und ändert die Zeile:
#greeter-wrapper=
Orca für die Anmeldung aktivieren:
greeter-wrapper=/usr/bin/orca-dm-wrapper
Weiterhin empfielt der Originaltext, den Benutzer "lightdm" der Audio-Gruppe hinzuzufügen, was nach meinen Erfahrungen jedoch unnötig ist. Wer es dennoch tun möchte:
sudo usermod -a -G audio lightdm

Vor dem Neustart

Wurden alle Änderungen gespeichert, ist der sprechende Raspberry Pi fertig eingerichtet. Im englischen Artikel wird noch der Speakup-Screenreader installiert, um auch auf der Shell außerhalb des Desktops mit Sprachunterstützung arbeiten zu können. Hierfür müsste allerdings Mate so konfiguriert werden, dass statt Pulseaudio auf Alsa zurückgegriffen wird, da Pulseaudio Speakup sonst blockiert, sobald man sich am Desktop angemeldet hat. Daher gehe ich auf diesen Abschnitt hier nicht ein. Das Mate-Terminal ist problemlos mittels Orca nutzbar. Für den direkten Shell-Zugriff kann entweder die übliche SSH-Verbindung oder BRLTTY genutzt werden, sofern man Besitzer einer Braillezeile ist.
Soll der Pi sofort in den Desktop booten, muss im Tool Raspi-Config noch in den Boot-Optionen die entsprechende Auswahl getroffen werden. Hier lässt sich auch einstellen, dass der Benutzer Pi via Auto-Login angemeldet wird, der Desktop ist dann sofort verfügbar. Nun noch den Raspberry Pi mittels sudo reboot neustarten, und sofern alles korrekt konfiguriert wurde, darf man sich über ein sprechendes Desktop-System freuen.

Die Auswahl an Anwendungen ist bei diesem Setup natürlich gering. Es ist weder Webbrowser noch E-Mail-Client installiert, was aber dank umfangreicher Paketverwaltung kein großes Problem darstellt. Firefox/Iceweasel ist nutzbar, wenn auch natürlich nicht für umfangreiche Webseiten oder tausende von Tabs gedacht. Als E-Mail-Client kann ich Sylpheed empfehlen, eine schlanke Alternative zu Thunderbird bzw. Icedove. Ob Libreoffice reibungslos läuft, habe ich bislang nicht getestet. Für einfache Textdateien ist aber der Pluma-Editor allemal gut genug. Wofür man den Desktop nutzt, muss jeder für sich selbst entscheiden. Alle Anwendungen lassen sich mit der Tastenkombination Alt-F1 im Menü erkunden.
Viel Erfolg!

DVB-Apps: Sendersuchlauf schlägt fehl

Geschrieben von Steffen Schultz keine Kommentare
Kategorisiert in : Software Schlüsselwörter : Debian, Linux, OpenSource, Video

Fernsehen unter Linux ist echt eine Wissenschaft für sich, aber ich wollte es mal wagen. Zum Einsatz kommt ein von Windows 10 befreiter MSI Cubi N sowie eine DVBSky S960 für den Satellitenempfang. Da ich den Rechner nicht ausschließlich zum Fernsehempfang benutze, habe ich mich für ein normales Debian Jessie entschieden, auch der für blinde Nutzer vollständig zugänglichen Installation wegen. Vielleicht werde ich es irgendwann auch noch mal mit einem meiner momentan arbeitslosen Raspberrys versuchen. Das System war binnen kurzer Zeit eingerichtet, wobei ich es mit einigen Backport-Paketen nachrüsten musste, da es z. B. Treiberprobleme und Anzeigeschwierigkeiten im X-Server gab. Auch die Firmware für die DVBSky-Box musste händisch nachinstalliert werden. Hier habe ich mich am OpenELEC-Firmware-Repository bedient und die Dateien dvb-demod-m88ds3103.fw sowie dvb-demod-m88rs6000.fw nach /lib/firmware kopiert. Zwar werden vom Hersteller ebenfalls Linux-Treiber angeboten, diese müssen jedoch selbst kompliliert werden, sofern ich die eher dürftige Dokumentation richtig verstanden habe.
Kleiner Tipp am Rande: Fehlende Firmware-Module lassen sich sehr bequem mittels Isenkram herausfinden und unter Umständen sogar automatisch nachinstallieren, sofern es sich nicht um proprietäre Software aus non-free oder von Drittanbietern handelt. Isenkram ist in den Debian-Paketquellen zu bekommen.

Die DVBSky-Box funktionierte problemlos, was ich mit einer hoffnungslos veralteten, aber zum Teil noch funktionierenden Channels.conf herausfinden konnte (Kann sich noch jemand an TM3 oder das ORB-Fernsehen erinnern?). Eine eigene Channels.conf zu erstellen schlug jedoch zunächst fehl:

steffen@Steffen-TV:~$ scan /usr/share/dvb/dvb-s/Astra-19.2E > ./channels.conf
scanning /usr/share/dvb/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
ERROR: cannot parse'[CHANNEL]'
ERROR: cannot parse' DELIVERY_SYSTEM = DVBS'
ERROR: cannot parse' FREQUENCY = 12551500'
ERROR: cannot parse' POLARIZATION = VERTICAL'
ERROR: cannot parse' SYMBOL_RATE = 22000000'
ERROR: cannot parse' INNER_FEC = 5/6'
ERROR: cannot parse' INVERSION = AUTO'
ERROR: initial tuning failed
dumping lists (0 services)
Done.

Eine Suche nach Möglichkeiten, diesen Fehler zu beheben, brachte wenig Resultate, bis auf den Tipp, es doch mal mit W Scan zu versuchen. Hier ist die Syntax zwar etwas komplexer, jedoch funktionierte der Sendersuchlauf auf Anhieb.

w_scan -fs -s S19E2 -E0 -X > channels.conf

Dieser Befehl startet einen Suchlauf nach allen frei empfangbaren Radio- und Fernsehprogrammen auf der Satellitenposition Astra 19,2° Ost, und gibt sie in einer Channels.conf-Datei aus, welche sich z. B. in Me TV, MPlayer oder jedem beliebigen Xine-Frontend nutzen lässt. Die Liste sollte jedoch zunächst sortiert werden, da sie sonst ziemlich unübersichtlich wirkt.

Als Nächstes werde ich verschiedene Programme für den Fernsehempfang austesten. Eine ähnlich komfortable Software, die es mit DVBViewer unter Windows aufnehmen kann, darf ich wahrscheinlich nicht erwarten, auch was die Einrichtung angeht. Derzeit nutze ich Me TV, was aber schon seit mehreren Jahren nicht mehr weiterentwickelt wird, bisher allerdings am unproblematischsten einzurichten war und sich auf die grundlegenden Dinge des Fernsehvergnügens beschränkt. Durch die Senderliste blättern, hin und wieder eine Aufnahme anfertigen. Auch spielt hier natürlich die Zugänglichkeit mit Orca eine große Rolle, was bei eher visuell orientierten Tools nicht immer selbstverständlich ist. Was müssen diese Blinden aber auch Fernseh gucken? :)

ProFTPD: Gelöschte Dateien bei abgebrochenem Upload

Geschrieben von Steffen Schultz keine Kommentare
Kategorisiert in : Software Schlüsselwörter : Debian, Linux, OpenSource

Dokumentationen sind gut, eigene Kreativität beim Umsetzen der Anweisungen ist aber auch nicht verkehrt - so jedenfalls meine Erfahrung des gestrigen Abends. Kopfzerbrechen bereitete mir da der ProFTPD-Server, welcher unter Debian Jessie offenbar recht seltsame Voreinstellungen mitbringt.

Ein neuer Server, ein neues Debian, ansonsten aber dieselben Software-Komponenten mit weitgehend identischer Konfiguration, das machte die Migration der Daten relativ einfach. Dann natürlich die vielen Kleinigkeiten und Tweaks, die man sich besser irgendwo notieren sollte, um sie beim nächsten Umzug wieder zur Hand zu haben. Manchmal treten jedoch auch neue Probleme auf, von denen vorher nie eine Rede war. So geschehen, als mich eine Freundin, die bei mir Webseiten und Dateien hostet, darauf aufmerksam machte, dass sie während FTP-Uploads Verbindungsabbrüche erleidet, welche die angefangenen Übertragungen komplett zurücksetzen, sodass sie mit dem Hochladen wieder von vorn anfangen muss. Bei großen Dateien und einer schmalen Bandbreite ist das natürlich ärgerlich. Also kurz gecheckt, ob auf dem Server alles in Ordnung ist. "AllowStoreRestart" war in "/etc/proftpd/proftpd.conf" wie erwartet auf "on" gesetzt, Netzwerkprobleme beim Server waren ebenfalls nicht erkennbar. Kurz noch mit einer eigenen Datei getestet, ob "AllowStoreRestart" tatsächlich greift, dann die Sache mit einem "liegt halt an deiner Verbindung" abgehakt, wie es sich für einen guten Hobby-Admin eben gehört, dessen Fußvolk ohnehin alle Probleme selbst verursacht. :)

Tja, wenn da diese "penetranten" User nicht wären. Die Verbindungsabbrüche blieben, also habe ich im Weltnetz nach möglichen Ursachen und Lösungen geforscht. Jemand schlug vor, ganz einfach die Timeout-Einstellungen auf 0 zu setzen, sodass der Server die Verbindung geöffnet hält. Hmm, wann er unter der Last hunderter offener TCP-Verbindungen wohl zusammenbrechen würde? Nein, das war also keine Option.

Der ausschlaggebende Hinweis kam dann jedoch von meiner Freundin, die dadurch von jeglicher Mitschuld freigesprochen war, sieht man mal davon ab, dass die Verbindungsabbrüche durch ihr wackliges WLAN passierten. Entscheidend zur Problemfindung war, dass nur jene Dateien, die korrekt während des Uploads pausiert wurden, auf dem Server erhalten blieben und später fortgesetzt werden konnten. Wurde eine Verbindung aber unerwartet unterbrochen, verschwanden die bisher hochgeladenen Daten vom Server, und man musste von vorn anfangen. Dies konnte ich zweifelsfrei reproduzieren, also ging die Suche jetzt zielgerichtet weiter.

Fündig wurde ich recht schnell in der ProFTPD-Dokumentation. Die Option "DeleteAbortedStores" sah ganz danach aus, als könnte sie mir weiterhelfen, aber:

The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded HiddenStores files if the transfer is stopped via the ABOR command rather than a connection failure.

Diese Option war also nur im Zusammenhang mit der Option "HiddenStores" verwendbar und zudem standardmäßig deaktiviert, wollte man der Dokumentation glauben. "HiddenStores" wiederum sorgt dafür, dass Dateien temporär als versteckte Dotfiles hochgeladen werden, erst nach vollständigem Upload werden sie umbenannt. Ebenfalls eine Option, die standardmäßig deaktiviert ist - und es auf meinem Server auch war, was ich während des Transfers beobachten konnte.

Nun, es vergingen weitere grüblerische Minuten, bis ich mich dann dazu durchringen konnte, diese eigentlich unsinnig erscheinende Option dann doch einfach mal auszuprobieren. Also in der ProFTPD-Konfiguration die Option "DeleteAbortedStores" hinzugefügt und auf "off" gesetzt. Siehe da, nach einem Neustart des Dienstes funktionierten die Uploads wieder so, wie sie sein sollten. Offenbar war die Dokumentation in diesem Punkt schon etwas veraltet, wie ich wenig später herausfand, als ich eine leicht abgewandelte Formulierung in der Dokumentation des Mod_xfer-Moduls fand:

The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded files if the transfer is stopped via the FTP ABOR command (as opposed to a connection failure). By default, DeleteAbortedStores is off; however when HiddenStores is enabled, then DeleteAbortedStores is automatically enabled as well.

Hier greift "DeleteAborted"Stores" also nicht ausschließlich im Zusammenhang mit "HiddenStores". Durchaus denkbar, dass sich inzwischen entgegen der Dokumentation auch der Standardwert dieser Option geändert hat. Welchen Sinn es haben könnte, diese Option auf "on" zu setzen, ist mir aber schleierhaft.

Fall erledigt, Freundin wieder glücklich. Das nächste Mal überlege ich mir aber schlagkräftigere Argumente, damit endlich wieder der User die Schuld tragen kann! :)

Voxin 1.0 veröffentlicht, Unterstützung für Debian Jessie

Geschrieben von Steffen Schultz keine Kommentare
Kategorisiert in : Software Schlüsselwörter : A11Y, Debian, Linux, OpenSource, Orca

Screen-Reader-Nutzer unter Linux dürfen sich freuen: Gestern wurde Version 1.0 der Voxin-Sprachausgabe veröffentlicht. Hierbei handelt es sich um die Linux-Portierung der von IBM entwickelten Text-To-Speech-Engine ViaVoice, die inzwischen zwar nicht mehr weiterentwickelt wird, sich jedoch nicht zuletzt durch den vom JAWS-Bildschirmleser bekannten Ableger Eloquence immer noch großer Beliebtheit erfreut. Da viele der zeitgemäßeren kommerziellen Sprachausgaben für Linux nicht verfügbar sind, ist Voxin momentan somit eine zwar proprietäre, aber eine der besten Alternativen zur quelloffenen eSpeak. Sie kann in Verbindung mit Speech-Dispatcher als Sprachausgabe mit Orca verwendet werden und ist auch im Audio-Desktop Emacspeak nutzbar.

Voxin wird von Oralux betreut, einer Non-Profit-Organisation, die sich für die Zugänglichkeit quelloffener Software einsetzt. Die Sprachausgabe an sich kann dabei nicht weiterentwickelt werden, wird aber an aktuelle Distributionen angepasst. Version 1.0 erschien nach einer längeren Pause und bringt unter anderem Unterstützung für Debian Jessie und Ubuntu 15.10/16.04 mit, außerdem wurde die Integration in 64-Bit-Systeme optimiert.

LibreOffice unter Debian aus GNOME entfernen

Geschrieben von Steffen Schultz keine Kommentare
Kategorisiert in : Software Schlüsselwörter : Debian, LibreOffice, Linux, OpenSource

Möchte man LibreOffice unter GNOME deinstallieren, um es gegen die aktuellste Version auszutauschen oder ganz einfach nur loszuwerden, stößt man sehr bald auf ein gravierendes Problem:

sudo apt-get purge libreoffice*
Paketlisten werden gelesen...
Abhängigkeitsbaum wird aufgebaut....
Statusinformationen werden eingelesen....
Paket »libreoffice-filter-binfilter« ist nicht installiert, wird also auch nicht entfernt.
Paket »libreoffice-filter-mobiledev« ist nicht installiert, wird also auch nicht entfernt.
Paket »libreoffice-help-en« ist nicht installiert, wird also auch nicht entfernt.
[...]
Die folgenden Pakete werden ENTFERNT:
gnome* libreoffice* libreoffice-avmedia-backend-gstreamer* libreoffice-base* libreoffice-base-core* libreoffice-base-drivers* libreoffice-calc* libreoffice-common* libreoffice-core* libreoffice-draw* libreoffice-evolution* libreoffice-gnome* libreoffice-gtk* libreoffice-help-de* libreoffice-help-en-us* libreoffice-impress* libreoffice-java-common* libreoffice-l10n-de* libreoffice-math* libreoffice-report-builder-bin* libreoffice-sdbc-firebird* libreoffice-sdbc-hsqldb* libreoffice-style-galaxy* libreoffice-style-tango* libreoffice-writer* mythes-de* mythes-de-ch* mythes-en-us* python3-uno* unoconv*
0 aktualisiert, 0 neu installiert, 30 zu entfernen und 1 nicht aktualisiert.

Wie man sieht, deinstalliert das Entfernen von LibreOffice scheinbar auch den Gnome-Desktop. Wird die Deinstallation fortgesetzt, passiert zunächst jedoch nicht viel. LibreOffice wird deinstalliert, ebenso das Paket GNOME. Hierbei handelt es sich allerdings nur um ein sogenanntes Metapaket, also ein virtuelles Paket, das zur Installation mehrerer Pakete genutzt wird. Deinstalliert man also das Paket GNOME, wird nicht der gesamte Desktop sofort deinstalliert, sondern die von diesem Paket abhängigen Pakete zunächst als Ballast im System gekennzeichnet, der sich theoretisch mit dem Befehl "sudo apt-get autoremove" entfernen lässt.

Paketlisten werden gelesen...
Abhängigkeitsbaum wird aufgebaut....
Statusinformationen werden eingelesen....
Die folgenden Pakete werden ENTFERNT:
argyll cheese file-roller finger firebird2.5-common firebird2.5-common-doc firebird2.5-server-common fonts-lyx fonts-opensymbol fonts-sil-gentium fonts-sil-gentium-basic gedit gedit-common gedit-plugins gir1.2-gdata-0.0 gir1.2-goa-1.0 gir1.2-gucharmap-2.90 gir1.2-rb-3.0 gnome-color-manager gnome-documents gnome-games gnome-nettool gnome-sudoku gnome-video-effects hamster-applet iagno icedtea-netx icedtea-netx-common iputils-tracepath libdiscid0 libfbclient2 libfbembed2.5 libgpod-common libgpod4 libhyphen0 libmythes-1.2-0 libnatpmp1 libsofia-sip-ua-glib3 libsofia-sip-ua0 lightsoff lp-solve media-player-info openjdk-6-jre python-wnck quadrapassel rhythmbox rhythmbox-data rhythmbox-plugin-cdrecorder rhythmbox-plugins seahorse simple-scan sound-juicer swell-foop telepathy-rakia transmission-common transmission-gtk uno-libs3 ure xdg-user-dirs-gtk xfonts-mathml

Spätestens hier sollte man abbrechen, möchte man sein Desktop-System nicht nahezu unbrauchbar machen. Wie also verhindern, dass die Pakete via autoremove entfernt werden? Im Grunde ganz einfach: Man markiert die betreffenden Pakete als manuell installiert. Hierfür ist der Befehl "apt-mark" zuständig. Um mir die Schreibarbeit etwas zu erleichtern, habe ich zunächst mit
sudo apt-get -s autoremove > ./Paketliste.txt
eine Simulation des Autoremove-Vorgangs in eine Textdatei umgeleitet. Diese wird dann mit einem Texteditor so bearbeitet, dass lediglich die Zeilen mit den zu entfernenden Paketen darin stehen, alle weiteren Zeilen darüber und darunter werden gelöscht. (Ja, vermutlich geht das auch einfacher über dpkg, dieser Befehl war jedoch nicht auf die Schnelle zu finden.) Um die Pakete nun als manuell installiert zu markieren, genügt der Befehl:
sudo apt-mark manual $(cat '/Pfad/zur/Paketliste.txt')
Die betreffenden Pakete sind nun nicht mehr als automatisch installiert gekennzeichnet und sind via "apt-get autoremove" auch nicht mehr entfernbar. Somit hätten wir LibreOffice also ohne Probleme aus Gnome entfernt.

Artikel-Feed (RSS) dieser Tag