
Hoppa Suse Leser und Leserinnen, gibt es für SBL optimale Einstellungen, die für Profile etc. nötig sind? Ich habe hier von Henning ein Profil für den VDr, welches das Navigieren im Menü möglich macht. Doch bei mir funktioniert das nicht. Er wies daraufhin auf Framebuffer und console-fonts hin. wie kann ich das System optimal für SBL einstellen? Ich nutze für den VDR das softdevice Plugin und u. A. als Modul radionfb. danke und -- Viele Grüße Sebastian ICQ: 264706583 | MSM: sebo@blinzeln.de | Skype: sebo_de E-Mail: sebo@aritamba.de | Web: www.blindzeln.de -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Am 06.07.07 um 08:03 schrieb Sebastian Dellit:
Er wies daraufhin auf Framebuffer und console-fonts hin.
Ja, framebuffer kannst Du im Bootloader deaktivieren. ein der Appendzeile könnte dann folgendes stehen: fb=false vga=normal in /etc/sysconfig/console stellst Du die Fonts ab: CONSOLE_FONT="none" CONSOLE_UNICODEMAP="none" Anschließend SuSEconfig nicht vergessen. ----- Du kannst mich jederzeit kostenlos per Festnetz erreichen unter: http://www.blindi.net/callback homepage: http://www.blindi.net

Hallo allerseits, On Thu, Jul 12, 2007 at 06:34:33AM +0200, Thomas Hoellriegel wrote:
Am 06.07.07 um 08:03 schrieb Sebastian Dellit:
Er wies daraufhin auf Framebuffer und console-fonts hin.
Ja, framebuffer kannst Du im Bootloader deaktivieren. ein der Appendzeile könnte dann folgendes stehen:
Bitte noch mal für mich: Warum genau soll man den Consolen-Framebuffer abschalten? Ich brauch den. Gruß -Klaus -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Am 12.07.07 um 11:20 schrieb Klaus Knopper:
Bitte noch mal für mich: Warum genau soll man den Consolen-Framebuffer abschalten? Ich brauch den.
Wenn der Framebuffer abgeschaltet wird, klappt die Cursorverfolgung / Bedinbarkeit von Programmen mit Sbl optimal. Die Darstellung ist: 25 Zeilen 80 Zeichen. So sind auch die Profile abgestimmt. Wird der Framebuffer nicht deaktiviert, wird man Probleme mit der Cursorverfolgung haben. Somit ist dann z.B.: mc, der Editor oder "Dialoganwendungen" nicht mehr wegen dieser anderen Auflösung nutzbar. Werden die Consolefonts / UTF8 deaktiviert, kann man die Umlaute richtig auf der Braillezeile lesen. Sollten diese Parameter nicht gesetzt sein. können Probleme beim Cursorrouting entstehen. Dies ist besonders hilfreich beim bearbeiten von Konfigurationsdateien. ----- Du kannst mich jederzeit kostenlos per Festnetz erreichen unter: http://www.blindi.net/callback homepage: http://www.blindi.net

On Fri, Jul 13, 2007 at 02:02:08AM +0200, Thomas Hoellriegel wrote:
Am 12.07.07 um 11:20 schrieb Klaus Knopper:
Bitte noch mal für mich: Warum genau soll man den Consolen-Framebuffer abschalten? Ich brauch den.
Wenn der Framebuffer abgeschaltet wird, klappt die Cursorverfolgung / Bedinbarkeit von Programmen mit Sbl optimal.
Mit eingeschaltetem Framebuffer klappt die Cursorverfolgung auch, sowohl Attributcursor als auch Hardcursor.
Die Darstellung ist: 25 Zeilen 80 Zeichen. So sind auch die Profile abgestimmt.
Mach ein fbset -xres 640 -yres 480 und schon hast Du 80x25 Zeichen. Alternativ: stty rows 25 columns 80 Dann is zwar nur ein Teil des sichtbaren Bildschirms belegt, aber es stimmt trotzdem alles exakt mit den auf 80x25 ausgelegten Profilen.
Wird der Framebuffer nicht deaktiviert, wird man Probleme mit der Cursorverfolgung haben.
Wie äußern sich die Probleme? Wir verwenden jetzt seit 2 Jahren sbl im Framebuffer-Modus, und hatten nie Probleme - oder haben wirs nur nicht gemerkt? Oder sind die Probleme neu in der sbl-Version 3.0?
Somit ist dann z.B.: mc, der Editor oder "Dialoganwendungen" nicht mehr wegen dieser anderen Auflösung nutzbar.
Probierst Du bitte mal mit den o.g. Einstellungen (fbset -xres 640 -yres 480 ; stty rows 25 columns 80) ob irgendwelche Probleme auftreten?
Werden die Consolefonts / UTF8 deaktiviert, kann man die Umlaute richtig auf der Braillezeile lesen.
Das interessiert mich auf jeden Fall. Wir werden für die Hindi-Übersetzung auf jeden Fall UTF-8 auf der Console brauchen. Es gibt keine Alternative. espeak ist auch auf UTF-8 ausgelegt. Welche Probleme hat sbl konkret mit UTF-8? Kann er Umlaute/Sonderzeichen einfach nicht erkennen, oder ist eine spezielle Filtereinstellung notwendig, damit es geht? UTF-8 ist für die Internationalisierung leider ganz, ganz wichtig! Auch in Frankreich wird hauptsächlich UTF-8 eingesetzt, obwohl es auch ohne ginge. Gruß -Klaus -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Hoppa Klaus und Leser und Leserinnen, am Freitag, 13. Juli 2007 um 10:53 meinte Klaus Knopper u. a.:
On Fri, Jul 13, 2007 at 02:02:08AM +0200, Thomas Hoellriegel wrote: Mach ein
fbset -xres 640 -yres 480
# fbset -xres 640 -yres 480 ioctl FBIOPUT_VSCREENINFO: Invalid argument
und schon hast Du 80x25 Zeichen.
Wenn kein Fehler kommt. *g*
Alternativ:
stty rows 25 columns 80
Dann erneut anmelden, nicht vergessen. Funktioniert aber, gerade getestet. Nur ist die Einstellung nach einem reboot wieder weg d. h. bei mir sind es dann wieder 64 Zeilen. :-( Wo kann man das dauerhaft einstellen? Henning hatte mir den Tipp bereits mal gegeben, nur hatte ich da nichts vom erneuten Anmelden gewusst, was ich jetzt aus Spaß probiert habe. Und scheinbar wird die Einstellung überschrieben, wenn man den FB mal aktiviert und wieder deaktiviert. -- Viele Grüße Sebastian ICQ: 264706583 | MSM: sebo@blinzeln.de | Skype: sebo_de E-Mail: sebo@blinzeln.de | Web: www.blindzeln.de -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

On Fri, Jul 13, 2007 at 12:31:58PM +0200, Sebastian Dellit wrote:
Hoppa Klaus und Leser und Leserinnen,
am Freitag, 13. Juli 2007 um 10:53 meinte Klaus Knopper u. a.:
On Fri, Jul 13, 2007 at 02:02:08AM +0200, Thomas Hoellriegel wrote: Mach ein
fbset -xres 640 -yres 480
# fbset -xres 640 -yres 480 ioctl FBIOPUT_VSCREENINFO: Invalid argument
Das sagt eigentlich (fast) aus, dass bei dir kein richtiger Framebuffer läuft. ;-) Oder einer mit unveränderlicher Größe, die man allerdings mit Kernel-Bootparametern auch setzen kann, z.B.: linux vga=785 Das wäre 640x480 mit Notebook-freundlichen 64000 Farben (könnte man z.B. für die Anzeige von Bildern für Sehende im Framebuffer-Modus, oder das Abspielen von Videos mit mplayer, nutzen).
Alternativ:
stty rows 25 columns 80
Dann erneut anmelden, nicht vergessen. Funktioniert aber, gerade getestet.
Ne, eigentlich nicht erneut anmelden. Das stty gilt ja nur für die aktuelle Textkonsole (oder Terminal-Fenster), und wird bei einigen Distributionen beim neu einloggen wieder zurückgesetzt. Für die aktuelle Shell kann man evtl. mit export ROWS=25 COLUMNS=80 nochmal explizit für ncurses-Programme die richtige Begrenzung setzen. Eventuell ist die korrekte Darstellung bei UTF-8 auch von der TERM-Variable abhängig. Beispielsweise hab ich mit elinks und UTF-8 nur Müll auf dem Bildschirm, wenn nicht TERM=linux gesetzt ist. vt100 und vt220 sowie xterm scheinen UTF-8 nicht richtig durchzureichen.
Nur ist die Einstellung nach einem reboot wieder weg d. h. bei mir sind es dann wieder 64 Zeilen. :-(
Wo kann man das dauerhaft einstellen?
In deiner .bashrc, oder /etc/profile, oder /etc/bash.bashrc, je nachdem, was bei deiner Distribution beim Einloggen ausgeführt wird. Ich habe es bei den ADRIANE-Skripten in das Haupt-Startskript eingebaut, so sind wir von den persönlichen Benutzer-Einstellungen unabhängig.
Henning hatte mir den Tipp bereits mal gegeben, nur hatte ich da nichts vom erneuten Anmelden gewusst, was ich jetzt aus Spaß probiert habe. Und scheinbar wird die Einstellung überschrieben, wenn man den FB mal aktiviert und wieder deaktiviert.
Die stty-Einstellung gilt nur für das aktuelle Terminal, und wird ggf. vom getty/login auch wieder zurückgesetzt. Außerdem gilt es nur für jeweils eine Console. Wenn's in der /etc/profile steht, dann wird es IMMER beim Einloggen ausgeführt, allerdings gibt es dann mitunter Fehlermeldung beim Einloggen per ssh, falls man nicht mit ssh -t arbeitet, was ein neues Termial alloziert. Aber das sind alles Feinheiten. Kann ich als Ergebnis meiner Nachfrage festhalten, dass der Framebuffer-Modus, wohlgemerkt mit den richtigen Terminaleinstellungen, offenbar doch kein Problem für sbl darstellt? Das wäre wichtig, denn unsere Live-CD soll ja gerade auch mit Framebuffer arbeiten, damit man auch mit mplayer Videos mit Bild abspielen kann. Jetzt wäre noch zu klären, wie wir UTF-8 in sbl handlen können. Prinzipiell scheint es ja zu gehen, d.h. sichtbar sind die Umlaute schon, obwhl sie bei UTF-8 ja aus zwei Zeichen bestehen. Nur müsste sbl das entsprechende Mapping verarbeiten können. Ob das automatisch geht, weiß ich nicht, vielleicht kann Marco was dazu sagen? Viele Grüße -Klaus -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Hoppa Klaus und Leser und Leserinnen, am Freitag, 13. Juli 2007 um 13:28 meinte Klaus Knopper u. a.:
On Fri, Jul 13, 2007 at 12:31:58PM +0200, Sebastian Dellit wrote:
fbset -xres 640 -yres 480
# fbset -xres 640 -yres 480 ioctl FBIOPUT_VSCREENINFO: Invalid argument
Das sagt eigentlich (fast) aus, dass bei dir kein richtiger Framebuffer läuft. ;-)
Gibt es auch "falsche"? ;-) # fbset mode "1280x1024-60" # D: 108.003 MHz, H: 63.983 kHz, V: 60.021 Hz geometry 1280 1024 1280 1024 8 timings 9259 248 48 38 1 112 3 hsync high vsync high rgba 8/0,8/0,8/0,0/0 endmode Das kommt nicht, wenn ich z. B. radeonfb deaktiviert habe.
Oder einer mit unveränderlicher Größe, die man allerdings mit Kernel-Bootparametern auch setzen kann, z.B.:
linux vga=785
Bei grub z. B. so? kernel /boot/vmlinuz-2.6.18-4-686 root=/dev/sda3 ro linux vga=785 Andere Optionen wie vga=normal fb=false deaktiviert?
Das wäre 640x480 mit Notebook-freundlichen 64000 Farben (könnte man z.B. für die Anzeige von Bildern für Sehende im Framebuffer-Modus, oder das Abspielen von Videos mit mplayer, nutzen).
Das wäre optimal. Mehr will ich gar nicht. :-) Will doch nur VDR ... *g*
Alternativ:
stty rows 25 columns 80
Dann erneut anmelden, nicht vergessen. Funktioniert aber, gerade getestet.
Ne, eigentlich nicht erneut anmelden. Das stty gilt ja nur für die aktuelle Textkonsole (oder Terminal-Fenster), und wird bei einigen Distributionen beim neu einloggen wieder zurückgesetzt.
Dann habe ich einen komischen Rechner, bzw. eine Distri, wo das nicht passiert. *g* Ich habe es gerade noch mal probiert. Wenn ich: # stty rows 25 columns 80 eingebe und dann: # set | grep line So steht dann da, das es 64 Zeilen sind. Melde ich mich ab und gleich wieder an, so steht dann bei einem: # set | grep -i line es handele sich um 25 Zeilen. Solange ich keinen reboot durchführe gilt das auf dieser Konsole, selbst wenn ich mich mit einem anderen User anmelde.
Für die aktuelle Shell kann man evtl. mit
export ROWS=25 COLUMNS=80
nochmal explizit für ncurses-Programme die richtige Begrenzung setzen.
Müsste das dann auch bei # set | grep -i line auftauchen? Manchmal ist es schon komisch. ;-) Danke und -- Viele Grüße Sebastian ICQ: 264706583 | MSM: sebo@blinzeln.de | Skype: sebo_de E-Mail: sebo@blinzeln.de | Web: www.blindzeln.de -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Hi, On Fri, Jul 13, 2007 at 04:34:37PM +0200, Sebastian Dellit wrote:
Hoppa Klaus und Leser und Leserinnen,
am Freitag, 13. Juli 2007 um 13:28 meinte Klaus Knopper u. a.:
On Fri, Jul 13, 2007 at 12:31:58PM +0200, Sebastian Dellit wrote:
fbset -xres 640 -yres 480
# fbset -xres 640 -yres 480 ioctl FBIOPUT_VSCREENINFO: Invalid argument
Das sagt eigentlich (fast) aus, dass bei dir kein richtiger Framebuffer läuft. ;-)
Gibt es auch "falsche"? ;-)
Jein, ich war nicht besonders ausführlich, sorry. ;-) Für fast jede Grafikkarte gibt es im Kernel ein Framebuffer-Modul, das neben dem einmalig "fix" eingestellten Modus (vga= Parameter) auch andere Modi on-the-fly einzustellen erlaubt. Wenn das fehlt, klappt auch fbset höchstwahrscheinlich nicht, und einige Grafikkaren (neuere Intel-Chipsätze) haben hne ihr zugehöriges Modul im Kernel gar keinen Framebuffer-Modus.
Oder einer mit unveränderlicher Größe, die man allerdings mit Kernel-Bootparametern auch setzen kann, z.B.:
linux vga=785
Bei grub z. B. so?
Ja. Man kann den Videomodus auch direkt mit rdev in den Kernel schreiben, ohne den Bootloader zu ändern: rdev -v /vmlinuz 785 womit der vga=-Parameter auch entfallen kann. Der wird vorwiegend vom Bootloader ausgewertet, um schon vor dem Kernel-Start im Real-Modus die Grafikkarte-Register entsprechend zu setzen, was nach Umschalten in den protected mode nicht mehr in jedem Fall funktioniert.
kernel /boot/vmlinuz-2.6.18-4-686 root=/dev/sda3 ro linux vga=785
Sollte stimmen.
Andere Optionen wie vga=normal fb=false deaktiviert?
Ja. Wir wollen ja Framebuffer.
Ne, eigentlich nicht erneut anmelden. Das stty gilt ja nur für die aktuelle Textkonsole (oder Terminal-Fenster), und wird bei einigen Distributionen beim neu einloggen wieder zurückgesetzt.
Dann habe ich einen komischen Rechner, bzw. eine Distri, wo das nicht passiert. *g* Ich habe es gerade noch mal probiert. Wenn ich:
# stty rows 25 columns 80
eingebe und dann:
# set | grep line
So steht dann da, das es 64 Zeilen sind.
Das sind zwei unterschiedliche Sachen. stty setzt das Texkonsolen-Größe und das Wrapping mehr oder weniger "hardcoded" auf das tty. Die Shell-Variablen hingegen sind "soft" und gelten für alle Programme, die diese Variablen auswerten. Das sind vorwiegend ncurses-gelinkte Programme. Man kann die Shell-Variablen unabhängig von stty setzen. Günstigenfalls aber für beide die gleichen. Die Shell bekommt es nicht unbedingt sofort mit, wenn man mit "stty" das Terminal umstellt. Um die Shell-Variablen auf die Terminal-Einstellungen anzupassen gab es früher mal in der xterm-Package ein Skript namens "resize", das man mit eval `resize` (Achtung: Backticks!) auch dazu benutzen konnte, die Shell-Einstellungen direkt nach stty bzw. Größenänderung des xterm-Fensters zu ändern. Ich glaube aber, das is nicht in jeder Distri dabei. Jedenfalls sollte für die laufende Bash ein export LINES=25 COLUMNS=80 bereits ausreichen. Ähm, "ROWS", was ich in der vorigen Mail geschrieben habe, war falsch, nur beim stty heißt es rows, in der bash aber LINES, sowohl COLUMNS als auch LINES großgeschrieben.
Müsste das dann auch bei
# set | grep -i line
auftauchen?
Ja, wenn man richtig LINES=25 statt ROWS=25 getippt hat. Mea culpa. ;-) Viele Grüße -Klaus -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Hallo Klaus und Leser und Leserinnen, so, kurz zu meinem Erfolg. ;-) Derzeit habe ich es so gemacht, wie du Klaus, und Halim es geschrieben haben. Zum einen lade ich im grub vga=normal, zum anderen habe ich in meiner /etc/profiles in der letzten Zeile stty rows 25 columns 80 Und wie mir scheint, funktioniert alles so, wie es soll, inkl. 25 Zeilen im FB. Danke und -- Viele Grüße Sebastian ICQ: 264706583 | MSM: sebo@blinzeln.de | Skype: sebo_de E-Mail: sebo@blinzeln.de | Web: www.blindzeln.de -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

hi, am besten probier folgendes: als kernelparameter verwende mal vga=normal. Damit wird der vesa framebuffer deaktiviert. Wenn du eine radeonkarte hast, lade einfach auf der konsole oder während des bootvorgangs den radeonfb. Der vesa framebuffer den man mit vga=xxx aktiviert bietet keinerlei hardwarebeschleunigung und sollte möglichst vermieden werden. Gruß Halim -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Hoppa Halim und Leser und Leserinnen, am Freitag, 13. Juli 2007 um 17:39 meinte Halim Sahin u. a.:
am besten probier folgendes: als kernelparameter verwende mal vga=normal. Damit wird der vesa framebuffer deaktiviert. Wenn du eine radeonkarte hast, lade einfach auf der konsole oder während des bootvorgangs den radeonfb. Der vesa framebuffer den man mit vga=xxx aktiviert bietet keinerlei hardwarebeschleunigung und sollte möglichst vermieden werden.
Und wie komme ich dann auf die 25 Zeilen? Danke und -- Viele Grüße Sebastian ICQ: 264706583 | MSM: sebo@blinzeln.de | Skype: sebo_de E-Mail: sebo@blinzeln.de | Web: www.blindzeln.de -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

hi, On Fr, Jul 13, 2007 at 06:31:05 +0200, Sebastian Dellit wrote:
Hoppa Halim und Leser und Leserinnen,
am Freitag, 13. Juli 2007 um 17:39 meinte Halim Sahin u. a.:
am besten probier folgendes: als kernelparameter verwende mal vga=normal. Damit wird der vesa framebuffer deaktiviert. Wenn du eine radeonkarte hast, lade einfach auf der konsole oder während des bootvorgangs den radeonfb. Der vesa framebuffer den man mit vga=xxx aktiviert bietet keinerlei hardwarebeschleunigung und sollte möglichst vermieden werden.
Und wie komme ich dann auf die 25 Zeilen?
wurde dir geschrieben schon. stty cols 80 rows 25 und trage das in die ~/.profile ein und gut. Gruß Halim
Danke und
Viele Grüße Sebastian ICQ: 264706583 | MSM: sebo@blinzeln.de | Skype: sebo_de E-Mail: sebo@blinzeln.de | Web: www.blindzeln.de
-- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org
-- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Hallo Klaus und Liste, Klaus Knopper wrote:
Welche Probleme hat sbl konkret mit UTF-8? Kann er Umlaute/Sonderzeichen einfach nicht erkennen, oder ist eine spezielle Filtereinstellung notwendig, damit es geht? UTF-8 ist für die Internationalisierung leider ganz, ganz wichtig! Auch in Frankreich wird hauptsächlich UTF-8 eingesetzt, obwohl es auch ohne ginge.
auf meinem Debian-System verwende ich BrlTTY und UTF-8. Auf der Konsole werden Sonderzeichen auf der Braillezeile richtig dargestellt. Vielleicht kann man sich etwas von BrlTTY abschaun. Viele Distributionen verwenden ja UTF-8 defaultmäßig. Daher sollte SBL damit schon klar kommen. VG Simon www.linux-fuer-blinde.de -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Hoppa Thomas und Leser und Leserinnen, am Donnerstag, 12. Juli 2007 um 06:34 meinte Thomas Hoellriegel u. a.:
Er wies daraufhin auf Framebuffer und console-fonts hin.
Ja, framebuffer kannst Du im Bootloader deaktivieren. ein der Appendzeile könnte dann folgendes stehen: fb=false vga=normal
Bei grub gibt es die Zeile IMHO nicht? Dort habe ich statt dessen: defoptions=fb=false vga=normal Was ja evtl. das gleiche bedeuten dürfte? Auf jeden Fall hat es noch nichts geholfen. Evtl. ist das auch nicht so einfach, wenn man - wie in meinem Fall - radionfb geladen hat?
in /etc/sysconfig/console stellst Du die Fonts ab: CONSOLE_FONT="none" CONSOLE_UNICODEMAP="none"
Das gibt es bei Debian nicht. :-( auch ein: # grep -iR -i console_fonts /etc Brachte kein Ergebnis.
Anschließend SuSEconfig nicht vergessen.
Was ist hier das Equivalent zu Debian? Danke und -- Viele Grüße Sebastian ICQ: 264706583 | MSM: sebo@blinzeln.de | Skype: sebo_de E-Mail: sebo@blinzeln.de | Web: www.blindzeln.de -- To unsubscribe, e-mail: blinux-de+unsubscribe@opensuse.org For additional commands, e-mail: blinux-de+help@opensuse.org

Am 12.07.07 um 17:00 schrieb Sebastian Dellit:
Bei grub gibt es die Zeile IMHO nicht?
Editiere die: /boot/grub/menu.lst Suche die Zeile mit dem Anfangswort kernel. Beipiel: kernel /boot/vmlinuz-2.6.18.8-0.3-default root=/dev/sdb2 vga=788 Den Vgaparameter änderst Du auf "normal". Nach dem abspeichern der menu.lst machst Du ein: grub-install /dev/bootplatte Dann sollte alles ordnungsgemäß funktionieren.
Das gibt es bei Debian nicht. :-(
auch ein:
Ok, dann hilft bei Dir ein: dpkg-reconfigure locales
Was ist hier das Equivalent zu Debian?
dpk-greconfigure locales oder: /etc/enviroment
----- Du kannst mich jederzeit kostenlos per Festnetz erreichen unter: http://www.blindi.net/callback homepage: http://www.blindi.net
participants (5)
-
Halim Sahin
-
Klaus Knopper
-
Sebastian Dellit
-
Simon Bienlein
-
Thomas Hoellriegel