Posts by Der Mike
-
-
Besten Dank!

Flippe ja gerade aus vor Freude!
(Man muss sich schließlich auch über die kleinen Dinge des Lebens freuen können.)
Gruß
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...

-
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...
-
Nach dem Upgrade von LXDE auf den Fork PIXEL ist hier teilweise so manches noch nicht deutsch lokalisiert.
So gibt es etwa im LXMenu noch "Run..." (anstatt "Ausführen...") und "Shutdown..." (anstatt "Herunterfahren...") zu finden.
Wo sind die entsprechenden Lokalisierungsdateien zu finden (Pfad), wo man dies korrigieren kann?
TIA
-
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...

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

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 ...Code
Display Morepi@pi-zero's password: Linux pi-zero 4.4.13+ #894 Mon Jun 13 12:43:26 BST 2016 armv6l _ _ __ (_) _______ _ __ ___ | '_ \| |____|_ / _ \ '__/ _ \ | |_) | |_____/ / __/ | | (_) | | .__/|_| /___\___|_| \___/ |_| Welcome to Raspbian GNU/Linux 8.0 (jessie) (4.4.13+). System information as of: Tue Sep 20 13:22:37 CEST 2016 System load: 0.29 IP Address: Memory usage: 9.9% System uptime: 8 days Usage on /: 26% Swap usage: 0.0% Local Users: 0 Processes: 105 Last login: Tue Sep 20 13:19:53 2016 from 192.168.1.122 pi@pi-zero:~ $
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
-
-
Ja, das weiß ich.
Allerdings geht es hier um die vollautomatische Ausgabe bei einem Log-in via SSH, siehe oben.
-
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
-
Vergleich mal was für ein User-Agent bei deinen Systemen übermittelt wird.Eine Auffälligkeit kann ich nicht erkennen.
-
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.)
-
Ja, aber weshalb "erkennt" Google hier Firefox als Mobil-Version?
-
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.000USERNAME@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 PackagesUSERNAMEi@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:104USERNAME@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...
