Posts by Der Mike

    Wo sind unter Raspbian Stretch eigentlich die Lokalisierungsdateien zu finden?

    Standard-Desktop "PIXEL", also LXDE.

    Insbesondere würde ich im Startmenü "Run..." und "Shutdown..." gerne auf Deutsch anpassen. (Aber auch einige Kontrollfelder der Preferences - 50 % oder so - sind aktuell überhaupt nicht lokalisiert.)

    Aber auch ansonsten hat Raspbian ja insbesondere seit Jessie ein arges Denglisch, woran man offenbar seit zwei Jahren auch so überhaupt nichts mehr geändert hat... :huh:


    Ja das muss ich auch sagen. Es fällt mir genauso auf.

    Das könnten die Entwickler wirklich mal verbessern.

    ...also entweder Englisch oder Deutsch aber nicht so ein halber Kram...

    Naja, da wurde halt schnell mal wieder "gehudelt" beim PIXEL-Desktop...

    LXDE an sich ist in zig Sprachen lokalisiert, die Entwickler des Forks PIXEL sitzen jedoch in England. Da wurde wohl alles außer British English so rein gar nicht getestet... (Das LXMenu ist nur ein Beispiel, fällt allerdings halt sofort ins Auge.)


    Plus sehr vieler wirklicher Bugs in den letzten Wochen...

    OK, Danke für die Rückinfo, dass das bei anderen Usern auch so ist!

    Haben noch andere hier das gleiche Problem?

    Irgendeine Idee für einen Workaround? Oder bleibt nur warten auf ein Update?
    Automatisch zusammengefügt:

    Der Fix ist da: :thumbs1:

    Die folgenden Pakete werden aktualisiert (Upgrade):
    lxpanel lxpanel-data
    2 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
    Es müssen 1.292 kB an Archiven heruntergeladen werden.

    War also tatsächlich ein Bug.

    Der "neue" PIXEL-Desktop hätte wohl besser noch drei oder sechs Monate bei den Entwicklern reifen sollen.

    Gefühlt kamen in den letzten drei Wochen seit Erscheinen locker 50 Updates via apt-get, was den LXDE-Fork PIXEL angeht... :denker:

    Dennoch: Gut, dass man hier sehr schnell reagiert hat! :bravo2:

    HTH
    Automatisch zusammengefügt:
    Screenshot:

    Nach den vielen Updates der letzten Tage/Wochen (LXDE -> PIXEL), was ja auch kaum was anderes ist als LXDE mit einem anderen Theme, hat es mir heute die Anwendungsstartleiste zerschossen.

    Alle Einträge sind weg, neue kann ich nicht hinzufügen.

    Auch ein manuelles Editieren via CLI ("sudo nano ~/.config/lxpanel/LXDE-pi/panels/panel") bringt nichts, nach einem Reboot ist alles wieder auf "Default", also leer. Die Datei wird schlicht überschrieben.

    Inhalt zur Launchbar:

    Plugin {
    type=launchbar
    Config {
    }
    }
    }

    Was ich gerne hätte:

    Plugin {
    type=launchbar
    Config {
    Button {
    id=pcmanfm.desktop
    }
    Button {
    id=/usr/share/raspi-ui-overrides/applications/lxterminal.desktop
    }
    Button {
    id=/usr/share/raspi-ui-overrides/applications/epiphany-browser.desktop
    }
    Button {
    id=/usr/share/applications/banshee.desktop
    }
    }
    }

    Habt ihr die gleichen Probleme?

    Bug? Workaround?

    Was auch gerne bei den zig Updates zu PIXEL passiert ist: Das Startmenü wurde wieder auf Default gesetzt, ebenso diverse .desktop-Dateien zu LXTerminal, PCManFM und Epiphany.

    Immerhin konnte das manuell via CLI jedesmal wieder repariert werden... :-/
    Automatisch zusammengefügt:
    Nachtrag: Über das grafische Tool (was eh empfohlen wird) kann ich auch keinerlei Einträge mehr hinzufügen. Wenn man auf "Hinzufügen" klickt, dann passiert rein gar nichts. :-/


    Servus Mike,
    Du kannst nach -> dieser Anleitung <- vorgehen.
    Klappt prima ...


    Jetzt brauchst Du das nur noch so anzupassen, wie Du es gerne hättest ;)

    cheers,
    -ds-

    Danke Dir, das ist eine praktikable Lösung. :)

    Gruß

    Mike


    Servus,
    die /etc/init.d/motd hat damit nichts zu tun.
    Das Geheimnis liegt in der /etc/motd ;)

    cu,
    -ds-

    Darin ist nur statischer Text zu finden, also dies:

    The programs included with the Debian GNU/Linux system are free software;

    the exact distribution terms for each program are described in the
    individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
    permitted by applicable law.

    Die Kernel-Angabe wird dynamisch erzeugt, doch offenbar nicht mehr unter Jessie. Und der Inhalt von /etc/motd ist unter Wheezy und Jessie hier absolut identisch (halt Lizenz-Gedöns, sonst nichts).

    Hallo!

    Unter Raspbian Wheezy wird mir beim Log-in via SSH der Kernel angezeigt:

    Linux raspberrypi 4.4.21-v7+ #911 SMP Thu Sep 15 14:22:38 BST 2016 armv7l

    The programs included with the Debian GNU/Linux system are free software;
    the exact distribution terms for each program are described in the
    individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
    permitted by applicable law.

    Nun hätte ich das auch gerne bei Jessie, wo es lediglich folgende Ausgabe gibt:

    The programs included with the Debian GNU/Linux system are free software;
    the exact distribution terms for each program are described in the
    individual files in /usr/share/doc/*/copyright.

    Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
    permitted by applicable law.

    /etc/init.d/motd scheint unter Wheezy und Jessie identisch zu sein, dennoch kommt es zu keiner Ausgabe der Kernel-Version.

    Woran mag das liegen?

    Danke für Tipps!

    Gruß

    Mike

    Ach, ich hatte die ganze Zeit Iceweasel installiert, also das Debian-umgelabelte Firefox.

    Vor zwei Wochen oder so wurde von apt-get die damals aktuelle ESR-Version von Iceweasel auf die nun aktuelle ESR-Version von Firefox aktualisiert. (Der jahrelange Namensstreit zwischen Mozilla und Debian wurde ja bekanntlich vor einigen Monaten beigelegt.)

    Es kann aber auch sein, dass Firefox auf einmal als zurückgehaltenes Paket von apt-get gemeldet wurde. Und ich dann noch "manuell" einen Anstoß via "sudo apt-get install firefox-esr" geben musste. Weiß ich nicht mehr. Jedenfalls wurde Iceweasel recht simpel ersetzt.

    Ich hätte allerdings nicht damit gerechnet, dass dies auch bei Wheezy ("oldstable") passieren wird, worauf meine installierte Raspbian-Version noch immer basiert.

    Ansonsten dürfte sich Firefox unter Debian/Raspbian mittlerweile einfach via "sudo apt-get install firefox-esr firefox-esr-l10n-de" installieren lassen. Zweites Paket wegen der germanischen Lokalisierung.

    Den Verdacht hatte ich auch zuerst.

    Der bewusste RPi läuft unter 1024x768.

    Testweise hatte ich mal mein ThinkPad unter Ubuntu MATE 16.04 LTS auf 1024x768 Pixel umgestellt. Dort tritt dieses Phänomen bei Firefox nicht auf. (OK, dort läuft die aktuelle Standard-Version, keine ESR-Variante wie unter Raspbian, doch sollte dies hier nicht relevant sein, da beide Versionen nicht sehr weit auseinander liegen.)

    Wie kann man Firefox 45.2.0 ESR unter Raspbian abgewöhnen, beim Aufrufen von "http://www.google.de/" immer die Mobile-Site aufzurufen?

    Siehe Screenshot.

    Ja, ich weiß, dass man auch "https://www.google.de/webhp?nomo=1&hl=de&gws_rd=ssl" als Websiteseite einstellen kann.

    Allerdings würde ich lieber wissen, weshalb die mobile Website von Google aufgerufen wird und nicht die Standard-Desktop-Site.

    Unter Chromium z.B. habe ich dieses Verhalten nicht.

    Danke für Tipps! :)

    Gruß

    Mike

    Egal, ob der NTP-Server der FRITZ!Box im Webinterface aktiviert ist oder nicht:


    USERNAME@raspberrypi:~$ ntpq -p
    remote refid st t when poll reach delay offset jitter
    ==============================================================================
    fritz.box 16 u 458 1024 0 0.000 0.000 0.000

    USERNAME@raspberrypi:~$ rdate -4npu fritz.box
    rdate: Ignoring NTP server with alarm flag set
    rdate: Unable to get a reasonable time estimate

    USERNAME@raspberrypi:~$ apt-cache policy dhcpcd

    dhcpcd:
    Installiert: (keine)
    Installationskandidat: 1:3.2.3-11
    Versionstabelle:
    1:3.2.3-11 0
    500 http://archive.raspbian.org/raspbian/ wheezy/main armhf Packages


    USERNAMEi@raspberrypi:~$ ps aux | grep -i dhcp
    ntp 2087 0.0 0.3 5392 3116 ? Ss 10:33 0:01 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /var/lib/ntp/ntp.conf.dhcp -u 102:104


    USERNAME@raspberrypi:~$ sudo netstat -tulpen | grep -i dhcp
    (Ohne Ausgabe)

    Noch stimmt die Zeit...

    USERNAME@raspberrypi:~$ cat /var/lib/ntp/ntp.conf.dhcp
    # This file was copied from /etc/ntp.conf with the server options changed
    # to reflect the information sent by the DHCP server. Any changes made
    # here will be lost at the next DHCP event. Edit /etc/ntp.conf instead.

    # NTP server entries received from DHCP server
    server 10.0.1.1 iburst

    # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

    driftfile /var/lib/ntp/ntp.drift


    # Enable this if you want statistics to be logged.
    #statsdir /var/log/ntpstats/

    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable


    # You do need to talk to an NTP server or two (or three).
    #server ntp.your-provider.example

    # pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
    # pick a different set every time it starts up. Please consider joining the
    # pool: <http://www.pool.ntp.org/join.html>


    # Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
    # details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
    # might also be helpful.
    #
    # Note that "restrict" applies to both servers and clients, so a configuration
    # that might be intended to block requests from certain clients could also end
    # up blocking replies from your own upstream servers.

    # By default, exchange time with everybody, but don't allow configuration.
    restrict -4 default kod notrap nomodify nopeer noquery
    restrict -6 default kod notrap nomodify nopeer noquery

    # Local users may interrogate the ntp server more closely.
    restrict 127.0.0.1
    restrict ::1

    # Clients from this (example!) subnet have unlimited access, but only if
    # cryptographically authenticated.
    #restrict 192.168.123.0 mask 255.255.255.0 notrust


    # If you want to provide time to your local subnet, change the next line.
    # (Again, the address is an example only.)
    #broadcast 192.168.123.255

    # If you want to listen to time broadcasts on your local subnet, de-comment the
    # next lines. Please do this only if you trust everybody on the network!
    #disable auth
    #broadcastclient
    Automatisch zusammengefügt:
    Ich habe nun heute das letzte Backup-Image von Anfang Juli wieder auf die SD-Karte aufgespielt.

    Zumindest momentan scheint die NTP-Synchronisierung zu funktionieren. Obgleich sie einige Sekunden von den anderen Rechnern hier im (W)LAN abweicht, warum auch immer. :s

    Interessant ist, dass alle von euch vorgeschlagenen Preferences-Dateien seit mindestens 2013 nicht mehr überschrieben bzw. geändert wurden, alle diesbezüglichen Dateien waren auf dem Stand von 2012 oder 2013. Auch vor der Rücksicherung nicht.

    Weshalb da nun auf einmal ein Konfigurationsproblem sein sollte - und es vorher jahrlang null Probleme gab -, das ist eigentlich eher... sagen wir mal nebulös... Entweder gab es einen Bug bei einem Raspbian-Update - "sudo apt-get update && sudo apt-get upgrade" wurde nach der Rücksicherung wieder ausgeführt - oder:

    Ich habe ja noch immer FRITZ!OS 6.3 im Verdacht, dass der dortige NTP-Server einen Bug hat bzw. sich nicht wirklich deaktivieren lässen, also auch nach einer Abwahl der entsprechenden Checkbox nicht.

    Allerdings habe ich nun den NTP-Server der FRITZ!Box wieder aktiviert, um zu sehen, ob es daran liegt: Noch stimmt die Zeit...

    Mal schauen, wie die nächsten Tage das Datum unter Raspbian sein wird.

    Ich nutze NTP nun schon seit dem klassischen Mac OS, also mindestens seit Version 9 von 1999, aber solche seltsamen Probleme hatte ich mit der Zeit-Synchronisierung noch nie... :huh: