Konfiguration des gpsd

Hinweis: In dem Thema Konfiguration des gpsd gibt es 20 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Ich möchte meinen aktuellen Stand zusammenfassen:


    In file:///etc/sysconfig/gpsd fehlt die Definition von DEVICE=/dev/ttyACM0
    Diese Variable wird NUR beim Start über service ausgewertet, nicht beim Start über uDev.
    Die Variable GPSD_PORT wird dagegen NUR beim Start über uDev ausgewertet, nicht beim Start über service.
    Der uDev-Start funktioniert nur wenn der Parameter GPSD_STARTBYUDEV="yes" auf yes gesetzt ist.
    Dem service ist der Wert dieses Parameters bei meinen Tests egal gewesen.


    In file:///usr/lib/systemd/system/gpsd.service muss diese Zeile auskommentiert werden:
    #Requires=gpsd.socket
    Soweit ich sah wird der weiter unten dort sichtbare Parameter OPTIONS in keiner Konfigurationsdatei gesetzt.


    Aufgrund eines Programmierfehlers im Daemon /usr/sbin/gpsd funktioniert das Binden an eine lokale IPv6-Adresse nicht.
    Interaktiv wird eine Fehlermeldung geworfen, wo sie nicht stört. Beim Start mit beiden Diensten ( service und uDev ) führt das zum Abbruch des Startvorganges.
    Das kann derzeit vermieden werden, wenn in file:///etc/sysconfig/gpsd mindestens die Option GPSD_OPTIONS="-G" enthält.


    In der Datei file:///usr/lib/udev/rules.d/51-gpsd.rules musste ich für meine Zwecke die folgende Zeile einfügen:
    KERNEL=="ttyACM*", ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a7", RUN="gpsd.sh"


    Alle anderen Zeilen dieser Datei verwenden ATTR statt ATTRS. Ich kann mir nicht vorstellen, dass dies dann trotzdem funktioniert, wenn es bei meiner Definition ungeeignet war.



    In der Datei file:///usr/lib/udev/gpsd.sh verstehe ich noch immer nicht unter welchen Voraussetzungen dieser Pfad verfügbar ist file:///dev/tcp/localhost/$GPSD_PORT.


    Entsprechend habe ich diese viert-letzte Zeile auskommentiert. Auch wenn ich den Sinn noch nicht verstanden habe, könnte an dieser Stelle folgende Zeile helfen:


    (sleep 1 && echo "F=$TTYDEV" | telnet localhost $GPSD_PORT & (je nach Zweck dieser Übung kann statt telnet auch netcat / nc eingesetzt werden.)


    Außerdem würde ich mir eine Auswertung der gesetzten Variable GPSD_PORT wünschen. Vorschlag: GPSD_PORT=$(echo $GPSD_PORT | awk '{print $NF+0}') .


    Damit wäre zumindest sichergestellt, dass ein numerischer Wert übergeben wurde (Bei Null könnte man dies ggf noch durch den Default-Port ersetzen.)



    Ich habe zudem gelernt, dass die Dateien file:///var/run/gpsd.socket, file:///var/run/gpsd.device und file:///var/run/gpsd.sock bei allen Starts erwartungsgemäß uninteressant sind.


    Die letzte Datei entsteht durch den Start als service, die anderen beim Start mit uDev beim Abarbeiten von file:///usr/lib/udev/gpsd.sh .
    Die Datei file:///etc/default/gpsd wird bei den vordefinierten Services referenziert, fehlt aber (sie wäre ein guter Ort für die Definition von DEVICES).
    Auch die Fehlermeldungen bzgl. var--run.mount,etc. beim Starten des falsch konfigurierten Service sind falsche Fährten.


    Mit den genannten Modifikationen funktioniert folgende Start-Sequenz

    systemctl enable gpsd.service ; systemctl start gpsd.service
    bei dem das Setzen des Ports in file:///etc/sysconfig/gpsd ignoriert wird.


    Das Starten mittels uDev gelang mir bisher nicht. Ich konnte zwar beobachten, dass das korrekte Kommando aufgerufen wurde, dann aber der Start abbrach.
    Interaktiv hat die von uDev generierte Kommandozeile funktioniert, nicht aber beim Einstecken, obwohl die gleiche Zeile gestartet worden war.
    Ich halte es für möglich, dass der ModemManager hier seine Finger im Spiel hat. Falls dies jemand lösen könnte, wäre mir diese Art des Starts erheblich lieber.


    Vielen Dank an meine Sparringspartner Sauerland und Berichtigung, die mich immer wieder in die richtige Richtung geschubst haben.


    Ich würde es gerne sehen, wenn diese Erkenntnisse in das Paket einfließen könnten. Ich wäre bereit das Paket zu aktualisieren, falls dies gewünscht wird.
    Leider weiß ich nicht, wie ich mich da sinnvoll einbringe.


    Andersfalls müsst ihr jedes Mal hier nachlesen, welche Kleinigkeiten angepasst werden müssen.


    Alles
    Anders


    Tipp: Wer Tippfehler findet darf sie behalten. Aber vielleicht gibt einer die fehlenden Kommata wieder zurück. ;)

  • ****soifz****

    Ich möchte meinen aktuellen Stand zusammenfassen:


    In file:///etc/sysconfig/gpsd fehlt die Definition von DEVICE=/dev/ttyACM0

    Das ist gut so. Das hat dort auch nichts verloren.


    Diese Variable wird NUR beim Start über service ausgewertet, nicht beim Start über uDev

    Was auch immer du mit "service" meinst: du irrst gewaltig.


    Udev ist das UserspaceDEVice System des Kernel. Es kümmert sich u.a. um das Hotplugging von Geräten. Beim Booten sorgt es dafür, dass alle Gerätedateien dynamisch erzeugt werden. Wenn du dann später in irgendeinen USB Port irgendein Gerät einsteckst, wird es ebenfalls aktiv und legt für dieses Gerät die Devicedateien DYNAMISCH an, verlinkt alles korrekt und stellt damit dem Kernel das frisch eingesteckte Gerät zum reibungslosen Betrieb zur Verfügung.
    Es legt, wie ich hoffte, längst erklärt zu haben, deine Gerätedatei /dev/ttyACMxx AUTOMATISCH BEIM EINSTECKEN an,
    Leider langst du ständig hin.


    Die Variable GPSD_PORT wird dagegen NUR beim Start über uDev ausgewertet, nicht beim Start über service.
    Der uDev-Start funktioniert nur wenn der Parameter GPSD_STARTBYUDEV="yes" auf yes gesetzt ist.
    Dem service ist der Wert dieses Parameters bei meinen Tests egal gewesen.

    Es ist völlig unklar, wovon du redest.


    Klar ist, dass Udev sich IMMER um das Anlegen und Verlinken der Gerätedateien kümmert.
    Völlig unabhängig, ob du deine Services modern via systemd oder antiquiert via SysV- Init startest, worauf dein Gebrauch des Wortes "service" hindeutet.
    Du brauchst auch in /etc/sysconfig NICHT rumzufummeln. Du hast ein gpsd.service File.
    Also kannst du die moderne Variante mit systemd verwenden. Nichts mit Scripten, nichts in /etc/sysconfig. Ganz einfach systemd. Und sonst nichts.
    (Dass sich der Hersteller nicht an die Konvention hält, dass solche Geräte in /etc/systemd und nicht in /usr/lib verwaltet werden, ist ein anderes Kapitel und beeinträchtigt weder die Funktion noch das Gesagte.)
    Du würfelst zwischen beiden mit gefährlichem Halbwissen hin- und her und wunderst dich, dass es nicht tut.


    In file:///usr/lib/systemd/system/gpsd.service muss diese Zeile auskommentiert werden:
    #Requires=gpsd.socket
    Soweit ich sah wird der weiter unten dort sichtbare Parameter OPTIONS in keiner Konfigurationsdatei gesetzt.

    Diese OPTIONS sind ja auch nur für systemd. Was die tun, kannst du in man 5 systemd.service nachlesen. Sie haben -außer in diesen NUR für systemd bestimmten Unit- oder Servicefiles- nirgends etwas verloren. Sie sind ohne systemd schlicht sinn- und bedeutungslos.
    Ob diese Zeile auszukommentieren ist, darüber kann man streiten.
    Linux verwendet Sockets so ziemlich überall.
    Mit Sockets wird nicht nur nahezu jede IPC (==InterProcessCommunication) abgewickelt, auch JEDE Netzwerkverbindung verwendet einen entsprechenden Socket.
    Wenn du so willst, ist eine Netzwerkverbindung ein Socket mit TCP/IP Verwaltungsgedöns drumrum.
    Mag sein, dass deine IPv6 Versuche aus diesem Mistverständnis®™ herrühren.


    Ich würde die Zeile keinesfalls auskommentieren. Denn hat dein GPS Empfänger keinen Netzwerkanschluss, hast du eine Netzwerksorge weniger.
    Und die paar Zahlen SIND rein lokal. Es gibt keinen vernünftigen Grund die Kommunikation deines Kernels mit diesem Empfänger via Netzwerksocket abzuwickeln. Aber du kannst es machen.
    Ich halt noch ein weiteres (Sicherheits)Loch. Sonst nichts. Immerhin ist es völlig überflüssig.


    Aufgrund eines Programmierfehlers im Daemon /usr/sbin/gpsd funktioniert das Binden an eine lokale IPv6-Adresse nicht.

    Klar. Wenn der Schreiber nichts taugt, hat die Feder schuld.


    Es ist noch lange nicht ausgemacht, ob das Gerät nicht locker eine IPv6 Adresse zur Kommunikation verwenden kann. Ich denke, das ist ebenso problemlos möglich, wie die vernünftigere Kommunikation via Socketfile.
    Leider fummelt da immer einer dazwischen.


    Interaktiv wird eine Fehlermeldung geworfen, wo sie nicht stört.

    In Linux hat JEDE Meldung Aussagekraft. Wir würden die gerne korrekt zitiert lesen. Sie helfen ungemein.
    JEDE Fehlermeldung unter Linux IST reiner KLARTEXT, falls man sie zu lesen gelernt hat.


    Beim Start mit beiden Diensten ( service und uDev ) führt das zum Abbruch des Startvorganges.

    Dein "service" IST KEIN Dienst. Und Udev - ob du das magst, oder nicht - kümmert sich darum. Egal, was du denkst. Egal, was du zerfigurierst. Du kommst an Udev NICHT vorbei.


    Das kann derzeit vermieden werden, wenn in file:///etc/sysconfig/gpsd mindestens die Option GPSD_OPTIONS="-G" enthält.

    Und was bewirkt die?
    Du kannst nicht davon ausgehen, dass hier auch nur einer das gleiche Gerät hat. Wirklich nicht.


    In der Datei file:///usr/lib/udev/rules.d/51-gpsd.rules musste ich für meine Zwecke die folgende Zeile einfügen:
    KERNEL=="ttyACM*", ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a7", RUN="gpsd.sh"

    Ich habe dir schon vielmals geschrieben, dass du diesen Unsinn lassen sollst. Vor allem bei deinem Wissensstand.


    Alle anderen Zeilen dieser Datei verwenden ATTR statt ATTRS. Ich kann mir nicht vorstellen, dass dies dann trotzdem funktioniert, wenn es bei meiner Definition ungeeignet war.

    Auch das ist offen dokumentiert. ATTR meint Attribut, und ATTRS ist schlicht der Plural. Technisch bezieht sich der Singular auf GENAU dieses eine Gerät, der Plural auf genau dieses Gerät samt allen Parents. Also bei einem an einem USB- Port eingestöpselten Gerät auf die Kette von PCI Controller zu PCI- Lane zu USB-Hub zu USB- Gerät. Einfach formuliert.
    Das spielt aber auch keine Rolle.
    Es würde ja alles längst laufen.
    Wenn nicht immer jemand - entgegen gute Rat - dran rumfummeln würde.

  • In der Datei file:///usr/lib/udev/gpsd.sh verstehe ich noch immer nicht unter welchen Voraussetzungen dieser Pfad verfügbar ist file:///dev/tcp/localhost/$GPSD_PORT.

    Die Bash hat ein Pseudofilesystem eingebaut. Damit kann man leicht Netzwerkverbindungen herstellen. Sowohl mit TCP, wie auch mit UDP.

    Diese drei Befehle genügen, um zumindest eine Fehlermeldung korrekt von Google zu erhalten.


    Entsprechend habe ich diese viert-letzte Zeile auskommentiert. Auch wenn ich den Sinn noch nicht verstanden habe, könnte an dieser Stelle folgende Zeile helfen:
    (sleep 1 && echo "F=$TTYDEV" | telnet localhost $GPSD_PORT & (je nach Zweck dieser Übung kann statt telnet auch netcat / nc eingesetzt werden.)
    Außerdem würde ich mir eine Auswertung der gesetzten Variable GPSD_PORT wünschen. Vorschlag: GPSD_PORT=$(echo $GPSD_PORT | awk '{print $NF+0}') .
    Damit wäre zumindest sichergestellt, dass ein numerischer Wert übergeben wurde (Bei Null könnte man dies ggf noch durch den Default-Port ersetzen.)

    Was für ein Käse!
    Es ist zwar heutzutage egal, wieviel Systemressourcen man verschwendet, aber die Lösung mit dem Pseudofilesystem ist immer schneller, als jedweder Aufruf von netcat, nc oder telnet. Ist ja schließlich Bash- intern, womit keinerlei Kontextwechsel, keine Prozessallozierung und all der Kram nötig ist.


    Dein eigenwilliger Vorschlag ist vom gleichen Kaliber. Dein Versuch den GPSD_PORT zu setzen, tut garantiert nicht das, was du denkst.
    Wenn irgendein String in der Variablen ist, hat die Variable danach immer den Wert 0.
    Steht eine einzige Zahl darin, tut sich scheinbar nichts.
    Stehen mehrere Zahlen darin, hat die Variable danach den Wert der letzten Zahl.
    Probier es aus und finde dann heraus, warum das gar nicht anders sein kann. Auch awk will gelernt sein.
    Shellprogrammierung ist ein sehr weites Feld.


    Den Rest spare ich mir jetzt, weil ich in die Heia will.
    Kann ich mir auch gut sparen,
    weil du als alter Profi es ja hingekriegt hast,
    das Ding zum Laufen
    und das System malade.

  • Hallo Berichtigung,


    Wie teilt man Deiner Ansicht nach dem Service gpsd mit, welches Gerät er starten soll ?
    Hast Du mich nicht gebeten von den Dateien in file:///usr/lib/systemd/system/ die Finger zu lassen?
    Oder anders herum, warum brauche ich eine Konfigurationsdatei, wenn ich die Paket-Dateien modifizieren kann ? (Ich glaube, das war Dir auch nicht recht.)
    Übrigens hätte es DEVICES=/dev/ttyACM0 heißen müssen und die Suche nach dieser Variable bei knapp 300 Diensten ergibt:

    Vielleicht wird hierbei auch klar, was ich meine, wenn ich von Services (dt: Diensten) spreche,
    die Du vorzugsweise mit systemctl startest, von denen viele aber auch auf service reagieren.


    In der Datei file:///usr/lib/systemd/system/gpsd.service muss die "Requires"-Zeile auskommentiert werden, damit es funktioniert.
    Diese Zeile verursachte die Socket-Meldung, die unter anderem den Start nach Deinen Wünschen verhinderte. (Kann man leicht ausprobieren.)
    Der besagte Socket wird erst beim Start des gpsd für die Steuerung angelegt.


    Ohne -G hört der gpsd nicht auf IPv6 und beschwert sich (hier im Klartext und der Port war nicht belegt):
    gpsd:ERROR: can't bind to IPv6 port gpsd, Cannot assign requested address
    Setzt man die Option -G, so erlaubt der gpsd INADDR_ANY und startet fehlerfrei. Ob es sich wirklich um eine lokale Adresse
    (wie bei IPv4) oder stattdessen um einen der IPv6-Multicasts bzw. ähnliches handelt kann ich bei dieser Fehlermeldung erst
    nach einem Blick in die Quellen sagen.


    Der "Käse" macht übrigens genau das, was er soll. Ob man an dieser Stelle Admin-Fehler abfangen soll, kann man jedoch berechtigt bezweifeln.


    Danke für Deine Erklärung zum Konstrukt mit dem Netzwerk-Filesystem der Bash. Wieder was gelernt.


    Ich würde mich freuen, wenn wir jetzt in der uDev-Variante klären könnten, warum der bereits mit den korrekten Argumenten gestartete gpsd immer wieder mit SIGCHLD aufgibt.
    Eine mögliche Ursache wäre der ModemManager, den ich nicht kenne.
    ___
    Die deutsche Wikipedia-Seite zu Sokrates zitiert[Quelle 57] die Interpretation von „Ich weiß, dass ich nicht weiß“:
    ""Im Sokratischen Reden und Denken liegt erzwungener Verzicht, [...] und die Flucht in den Dialog [...]""

  • @anders noergler
    Sag' bitte einmal was Dein Ziel ist. Interessieren Dich die GPS-Daten, so wie sie vom Empfänger geliefert werden? Oder willst Du ein Navi-System nutzen?
    (Ich bin nur neugierig :) . Sofern mir klar ist welches Ziel Du verfolgst, kann ich evtl. etwas sinnvolles beitragen?)

    be tolerant - not ignorant
    Alle Hunde sind schwarz.
    Es gibt einen Hund der nicht weiß ist.

    Für den Inhalt des Beitrages 118704 haftet ausdrücklich der jeweilige Autor: Boreas

  • ***soifzzzz***


    Dir ist der Unterschied einfach nicht klar zu machen.


    Das Programm service gehört zur veralteten Systeminitialisierung, dem sogenannten SysV Init System. (SysV == Unix System Vünf)
    Das stammt von AT&T aus der Digitalsteinzeit.
    Es setzt in den Verzeichnissen /etc/init.d/rc{0..5},rc{S,K} (und den Defaults für den Boot in /etc/default ) voraus. Diese Scripte werden nach einem bestimmten Namensschema benannt. (S== Start; K== Kill, und am Anfang eine zweistellige Zahl, die sortiert, die Reihenfolge der Abarbeitung festlegt.)


    Das moderne systemd hat den Vorteil, dass es, weil es keine strikte Reihenfolge gibt, alle Initialisierungen hoch parallelisiert starten kann. Es ist wesentlich schneller. Dazu verwendet es Unitfiles, die die jeweiligen Dienste konfigurieren. In /usr/lib liegen die vom Distributor festgelegten Systemdienste. Damit werden z.B. alle Mountoperationen ausgeführt, sämtliche Subsysteme initialisiert und deren jeweiligen Abhängigkeiten geordnet.
    Dort sollte man nicht drin rumfummeln. Dass es der Hersteller deines Gerätes dennoch tut, obwohl die empfohlene Variante die Konfiguration alles weiteren Geräte und Dienste in /etc/systemd verlangt, ist Faulheit, Nichtwissen, oder Sparsamkeit des Herstellers. Es bleibt unschön.


    Dass nun in /usr/lib/systemd/* der String "DEVICE" sehr oft auftaucht, ist selbstverständlich und keiner weiteren Erwähnung wert,
    außer für Profis, wie dich.
    Es ist selbstevident, dass es gar nicht anders sein kann. Guck einfach mal ein wenig in /dev herum. Es ist immer überraschend, wenn man das erste Mal sieht, wieviele Geräte ein Kernel von Haus aus bedient.


    Dir ist das egal.
    Du mischt munter beide Varianten der Systeminitialisierung.
    Leider gibt es aus Kompatibilitätsgründen noch ein Layer, das alte SysV Initscripte in die moderne Systemd Variante einbindet.
    Also fummeln -logisch gesehen- drei verschiedene Arten auf einem Gerät rum.
    Du wunderst dich noch immer, dass es nicht sauber läuft?
    Ein, und die richtig, genügt.


    Dann lass dir noch erklären, was du mit deinem irrsinnigen awk Kommando anrichtest:
    NF ist die awk- interne Variable NumberOfFields, die man durch ein vorangestelltes "$" zu ihrem Wert expandieren kann.


    echo 'Apfel Birne Citrone' | awk '{print $NF}' gibt Citrone aus, weil du das letzte Feld ausgibst.


    echo 'Apfel Birne Citrone' | awk '{print NF}' gibt "3" aus, weil es drei Felder gibt.
    echo 'Apfel Birne 12' | awk '{print NF}'  gibt, wie zu erwarten, wieder drei aus. Nicht die Anzahl der Felder, sondern nur der Inhalt von Feld#3 hat sich geändert.
    echo 'Apfel Birne 12' | awk '{print $NF}' und gibt den Inhalt, also "12" aus.
    Und du fängst nun mit der Variablen zu rechnen an.
    echo 'Apfel Birne 12' | awk '{print NF +5 }' Das ist noch klar, und gibt "8" aus, weil die Anzahl der Felder 3 plus 5 nun mal 8 ist.
    echo 'Apfel Birne 12' | awk '{print $NF +5 }' Das ist auch noch klar, und gibt 17 aus, weil der Inhalt in Feld3# 12 ist und wir + 5 draufzählen.
    echo 'Apfel Birne Citrone' | awk '{print $NF +5 }' gibt "5" aus, weil der Inhalt von Feld#3 "Citrone" erst implizit in eine Zahl umgewandelt werden muss, damit man dann damit die Addition + 5 ausführen kann. Diese Umwandlung ergibt für Strings immer 0. Böses Foul.
    Damit wird nämlich dein übles Konstrukt im Falle eines Strings
    echo 'Apfel Birne Citrone' | awk '{print $NF + 0 }' IMMER "0" ausgeben.


    Das wird ganz besonders doof, wenn man weiß, dass im TCP/IP Stack Port 0 von der Iana mit "darf nicht verwendet werden" gekennzeichnet ist.
    Schlimmer noch, der Port 0 wird beim Linuxnetzwerkstack verwendet, um mitzuteilen, dass das System selbst irgendeinen freien Port suchen soll. Was i.d.R. irgendeine freie Portnummer im sehr hohen Bereich ist.


    Läuft es blöd, konfigurierst du also die sicherheitsbedenkliche Kommunikation deines GPS- Gerätes mit "Würfle mir irgendeinen Port".
    (Was wirklich in der Variablen steht, schreibst du ja nicht.)
    Wunderst du dich noch immer, dass es nicht so recht funktionieren will?


    Statt, wie es die Forenregeln fordern, präzise zu Schreiben, was Sache ist, schreibst du irgendwelche Mutmaßungen über Linux, die allesamt falsch sind.
    Du postest weder das Script, noch das Service/Unitfile. Was in der Variablen drinsteht auch nicht.
    Freust dich, wenn zufällig das Ergebnis passt, ohne Rücksicht darauf, was du damit anrichtest.
    Vorsätzlich subtile Fehler einbauen ist dumm.


    Dabei wäre dein Gerät längst via Socketfile in Betrieb, wenn du schlicht hören würdest.
    Mir ist das jetzt endgültig egal.
    Freue dich, dass dein GPS immerhin zwischendurch manchmal ein wenig geht.

  • Ihr wollt es aber heute genau wissen ...


    Boreas: Ich möchte WGS84-Information empfangen und relativ zu einem veränderlichen Standort darstellen.


    Berichtigung:
    Die Erstinstallation funktionierte bei mir nicht (so wie du es beschrieben hast). Also bat ich einen Freund mich zu unterstützen
    und seine letzte Konfig-Datei (bevor er aufgab) enthielt GPSD_PORT="-S 2999".
    Es war wohl eher eine Verzweiflungstat, aber hat mich etwas sensibilisiert. Insofern war diese Auswertung beabsichtigt.
    (Ich habe erst versucht das Ganze mit Shell-internen Konstruktionen zu erledigen, scheiterte aber immer an der Typenkonvertierung,
    wenn ich bei Strings mit Leerzeichen oder mehreren Einträgen mit test "$GPSD_PORT" -gt 0 prüfen wollte um ggf den Defaultwert 2947 zu verwenden.)
    Aber man kann nicht alles abfangen und ich habe auch eingestanden, dass ein Admin Fehlermeldungen lesen und verstehen können sollte.
    Andererseits waren in diesem Fall mehrere "Besonderheiten" zu finden, was es nicht einfacher machte.


    Dieses Paket ist übrigens aus der Distribution Application:Geo / openSUSE_Leap_42.3 - also nicht von U-Blox.


    Da das Paket und damit das Skript frei zugänglich sind (ich dachte im Hauptrepository), habe ich das Skript erst in Eintrag 3 gepostet.
    Mein Ziel ist es lediglich ein Paket zu haben, das dessen Beschreibung entspricht und es auch den anderen bereitzustellen.
    (Wenn schon nicht das Paket, dann zumindest die erforderlichen Korrekturen.)


    Aus meiner Sicht gibt der Eintrag 11 ca. 90% dessen wieder, das man bei dem Paket gpsd korrigieren muss.
    Klar gibt es andere Lösungswege (Sauerland hat auf einen hingewiesen), aber ich will das Modul einstecken und es läuft.
    Stellt Euch vor, ihr hättet diese Odyssee mit jeder neuen Tastatur oder Maus. (Der eine oder andere erinnert sich noch daran.)


    Jetzt setze ich mich an die "letzten 10%".

  • @Boreas hat einige dieser Teile laufen.
    Warum es wohl bei ihm so einfach geht?
    Wirklich, ganz einfach einstecken, gucken, welches tty, und schon ist alles gut, alles tut.


    Du wählst einen anderen Weg.
    Erst das System puttspielen.
    Dann verzweifelt noch mehr subtile Fehler einbauen.
    Und hier nicht Infos nach Forenregeln posten, sondern hausgemachte Phantasien, wie etwas sein könnte.

  • Ich habe angenommen, das Paket gpsd wäre bei openSUSE Leap 42.3 einigermaßen aktuell, wenn es eine aktuelle Versionsnummer trägt:

    Code
    # rpm -q gpsd
    gpsd-3.17-98.2.x86_64
    
    
    # zypper lr -uP
    #  | Alias                                 | Name                                                                                           | Enabled | GPG Check | Refresh | Priority | URI                                                                               
    ---+---------------------------------------+------------------------------------------------------------------------------------------------+---------+-----------+---------+----------+-----------------------------------------------------------------------------------
     1 | Application_Geo                       | Applications related to the earth (GIS, Mapping, geodesy, GPS, astronomy) (openSUSE_Leap_42.3) | Yes     | (r ) Yes  | Yes     |   99     | http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Leap_42.3/

    Die neuesten Sources (gpsd 3.17) von GPSd — Put your GPS on the net! überzeugen einem vom Gegenteil.


    Es gibt bereits auf den ersten Blick eine umfassendere Integration, mehr Informationen und z.B. troubleshooting guides.
    Ein Vergleich mit der Version 3.0 zeigt, dass die Integration von V3.0 neuer bzw. weniger verstümmelt ist als diejenige,
    die Leap 42.3 als gpsd-3.17-98.2.x86_64 anbietet - oder muss man die Versionsnummern rückwärts lesen?
    Überraschenderweise ist der eigentliche gpsd tatsächlich neueren Datums, vielleicht sogar wirklich 3.17 -
    ich konnte dessen Hilfetext (weicht von 3.16 ab), aber nicht den IPv6-Fehler mit einem Eigenkompilat reproduzieren.
    Niemand hat behauptet, openSUSE V3.17 ist die Original V3.17, aber ein Paket lebt aber auch von seiner Integration.



    Neugierig habe ich es unter Ubuntu installiert:
    - GPS-Empfänger anstecken und er geht
    - alle "eigenwilligen Vorschläge" aus Eintrag 11 sind dort fast genauso umgesetzt, und natürlich noch einiges mehr.
    - leider ist es wohl nur Version 3.15, die im Ubuntu 16.04.3 Repository liegt. - aber es sieht aus wie die richtige 3.15 und verhält sich aus so


    Code
    # dpkg -l gpsd
    Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
    | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
             Halb installiert/Trigger erWartet/Trigger anhängig
    |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
    ||/ Name                                                           Version                              Architektur                          Beschreibung
    +++-==============================================================-====================================-====================================-=================================================================================================================================
    ii  gpsd                                                           3.15-2build1                         amd64                                Global Positioning System - daemon


    Ich hatte mich schon gewundert. So unpopulär schien mir das Paket nicht zu sein.


    Vor diesem Hintergrund mag jeder selbst die Aussagen zu Phantasien, Regeln und Subtilitäten beurteilen:

    Du wählst einen anderen Weg.Erst das System puttspielen.
    Dann verzweifelt noch mehr subtile Fehler einbauen.
    Und hier nicht Infos nach Forenregeln posten, sondern hausgemachte Phantasien, wie etwas sein könnte.


    Ich habe meine Meinungen klar als solche gekennzeichnet und für das meiste Quellen genannt. Das halten hier aber nicht alle so.
    2 Abende meiner Lebenszeit für ein schlecht gepacktes Fake-Paket aufzuwenden, hinterlässt Spuren:
    Außer bei aufkommenden Interesse an Unterstellungen, Fakes und Troll-Bots werde ich wohl openSUSE und Anfänger künftig versuchen professionell zu meiden.
    Einige informative Sektionen sind hier durchaus zu finden, aber vergleicht die "Ratschläge" hier mit dem Original.


    Urteilt selbst und
    Orientiert Euch
    Anders
    ___
    Die deutsche Wikipedia-Seite zu Sokrates zitiert[Quelle 57] die Interpretation von „Ich weiß, dass ich nicht weiß“:
    ""Im Sokratischen Reden und Denken liegt erzwungener Verzicht, [...] und die Flucht in den Dialog [...]""