Ich habe ja auch ab und an so meine Differenzen mit
@cuma, aber die Frage:
Was bedeutet in diesem Fall "invalid"?
ist ja hoffentlich nicht wirklich ernst gemeint, oder?
Für welches Modell und welche AVM-Version Du da irgendetwas übersetzen wolltest, muß man selbst aus dem Titel der Issue ableiten - welcher Fehler genau auftritt und unter welcher Build-Umgebung, soll man dann auch selbst raten? Welche anderen Einstellungen in der
.config noch so gesetzt waren auch?
Was ist denn, wenn das Problem am Ende tatsächlich auf Deinem System existiert und Du das nur falsch als "Freetz-NG-Problem" beurteilst? Soll man jetzt tatsächlich erst noch einmal selbst probieren, ob das auf dem eigenen System funktioniert? Was ist denn, wenn das dort klappt? Entschuldigst Du Dich dann für die Wellen, die da gemacht wurden?
Wenn man erwartet, daß andere für einen Fehler suchen, muß man ihnen schon die notwendigen Informationen liefern, damit sie sowohl die Randbedingungen genau(!) kennen, als auch sich selbst eine Meinung dazu bilden können, wo das Problem am wahrscheinlichsten liegt. Wenn Du selbst das so genau weißt bzw. wüßtest, bräuchtest Du ja vermutlich diese Hilfen nicht - also mußt Du den "Problemlösern" dann schon zugestehen, daß die sich eine eigene Meinung zum (oft auch nur vermeintlichen) Problem bilden.
Ich empfehle Dir (ganz konkret Dir) daher, mal diese Quelle zu lesen:
https://www.chiark.greenend.org.uk/~sgtatham/bugs-de.html - der Autor ist gleichzeitig derjenige, der den (von vielen verwendeten) SSH-Client PuTTY "verbrochen" hat ... also auch niemand, der von der Materie (gerade hinsichtlich "unqualifizierter Fehlermeldungen") so gar keine Ahnung hätte und davon gar nicht betroffen wäre. Dem, was er da schreibt (und was dann jemand ins Deutsche übertragen hat), ist eigentlich nur wenig hinzuzufügen ... auch wenn der Text an sich schon etwas älter ist.
Und das gilt eben eigentlich auch für das andere Problem ... auch wenn es da wieder mit 7590 und 07.21 begann und das auch so im Titel steht, wechselt das auf einmal zur 7490 und zur 7430 und am Ende blickt wirklich niemand mehr durch, in welcher Konfiguration das Problem nun besteht und in welcher nicht. Wenn ich das bisher Gelesene richtig verstanden habe, ist das ja nun mindestens wieder ein Problem der 07.21-Version generell (oder zumindest für 7590 und 7490) - damit paßt der Titel schon wieder nicht mehr zum Inhalt der Problembeschreibung und das macht es nicht nur denjenigen schwerer, das irgendwie einzuordnen, die sich des Problems annehmen und es lösen wollen ... nein, auch nachfolgende Freetz(-NG)-Benutzer mit demselben Problem haben es dadurch schwerer und stehen jetzt vor dem Rätsel, ob sie für das gleiche Problem bei der 7490 nun eine eigene Issue aufmachen sollten oder nicht. Am Ende liest sich das jetzt so (und zwar hier:
https://github.com/Freetz-NG/freetz-ng/issues/131#issuecomment-750446207 im zweiten Anstrich), daß eine 7590 ohne den LTE-Stick und die Festplatte gar nicht mehr zu benutzen ist. Was hätte das dann noch mit dem Titel "7590 7.21: Telefonie über Mobilfunk wird in AVM Webconfig nicht angezeigt" zu tun und wer soll da noch durchblicken?
Da hilft es eben ungemein, wenn man selbst (so man das Problem nicht gelöst hat) seine Aussagen auf das beschränkt, was man tatsächlich weiß und entsprechend belegen kann und jede Spekulation über die möglichen Ursachen denjenigen überläßt, die sich damit (manchmal vielleicht auch nur vermeintlich) besser auskennen. Ein Titel "Telefonie über Mobilfunk wird in AVM Webconfig nicht angezeigt" hätte von Beginn an besser gepaßt, weil ja alle anderen Informationen (Konfiguration, Beschreibung des Build-Systems, "fmake"-Ausgabe des fehlerhaften Builds, etc.) im ersten Beitrag stehen würden.
Und es versteht sich eigentlich von selbst, daß man bei einem Problem auch erst einmal selbständig überprüft, ob das mit der AVM-Firmware und mit einem absoluten Minimal-Image auch auftritt, BEVOR man das als (Freetz/-NG-)Fehler meldet - wenn's am Ende dann doch eigene Änderungen sind (dafür gibt es ja die
.config, die man der Fehlermeldung hinzufügt, um das auch deutlich zu zeigen, was zur Reproduktion des Fehlers erforderlich wäre), ist das ja eher peinlich ... zumindest dann, wenn einem der eigene Ruf nicht ohnehin schon vollkommen egal ist.
Ich kann mich jedenfalls noch an Zeiten erinnern, wo VOR dem Eröffnen eines Tickets im Trac (und eine GitHub-Issue ist damit absolut vergleichbar) erst einmal in einem BBS (primär hier) geklärt wurde/werden sollte, ob es sich tatsächlich um ein Problem des Projekts oder nur ein Problem der Handhabung handelte ... die "Anleitungen" lesen sich eigentlich (in beiden Forks) auch immer noch so:
Freetz-NG firmware modification for AVM devices like FRITZ!Box - Freetz-NG/freetz-ng
github.com
freetz.github.io
und ich verstehe nicht wirklich, warum man davon abweichen wollte oder sollte (und wer sich selbst nicht mehr als "newbie" sieht, der sollte das kleine Einmaleins der Fehlerberichte eigentlich aus dem Effeff beherrschen).
Wenn man tatsächlich "Benutzerfehler" in den entsprechenden GitHub-Repos diskutieren will (oder zumindest erst mal richtig abklären will, wo das Problem nun tatsächlich liegt), dann sollte man eher zu der (neuen) Funktion mit den "Discussions" greifen (das muß der Repo-Owner aber freischalten, ist Beta iirc):
, weil man damit seine Issue-Liste auch von solchen (gerne auch mal sinnlosen/falschen/unvollständigen) Einträgen frei halten kann.
Wie man auch unter dem o.a. Link zum Text von 1999 nachlesen kann, sollte man als "Fehlermelder" aber trotzdem immer erst mal davon ausgehen, daß das (zumindest beim Autoren) ja schon mal funktioniert haben sollte (ja, ich weiß auch, daß das nicht immer 100% stimmt - aber man kann es bis zum Beweis des Gegenteils ja trotzdem annehmen) und so sollte man sich erst dann zum "Ich habe da einen Fehler bei Dir gefunden." hinreißen lassen, wenn man sich da auch wirklich sicher ist. Spätestens beim zweiten Mal sollte man das gelernt/verstanden haben.
Ich finde jedenfalls keine Issue (und erst recht keine Diskussion zuvor, die ja dann wohl hier geführt worden wäre), in der die "zwei Probleme" aus #76 auch mal in dieser Form thematisiert wurden ... wobei mich schon die Aussage:
Die 7590 7.21 mit aktueller Freetz-NG GIT Version stürzt mit oder ohne LTE Stick reproduzierbar ab.
vollkommen verwirrt, denn wenn das sowohl mit als auch ohne LTE-Stick geschieht, warum steht dann da nicht "immer" und was hat das dann noch mit dem Thema "LTE-Stick" an sich zu tun? Warum schreibt man dann nicht "Die 7590 7.21 mit aktueller Freetz-NG GIT Version stürzt mit oder ohne DynDNS-Account reproduzierbar ab."?
Und auch hinsichtlich der Fehlerbeschreibungen ist da noch deutlich "Luft nach oben" ... wenn ich hier lese:
Alle 3 Boxen unterstützen mit Original AVM Firmware das Telefonieren über GSM/UMTS Telefonie mit einem 4G Systems W1208 Stick. Mit einer freetz-ng Firmware auf Basis der gleichen AVM FW Version funktioniert das jedoch nicht.
, dann frage ich mich wiederum, woher
@Fox.Mulder das wissen kann, wenn es doch unter Freetz-NG gar keine Möglichkeit mehr gab/gibt, das überhaupt zu konfigurieren?
Ein "funktioniert nicht" und ein "Einstellmöglichkeiten fehlen" sind ja ganz offensichtlich nicht wirklich dasselbe ... und auch bei einem "Reset" kann man - als derjenige, der eine Fehlerbeschreibung abgibt - ganz leicht selbst dafür sorgen, daß es nicht zu Mißverständnissen kommt. Denn ein "factory reset" (als ein Neustart mit Werkseinstellungen) ist eben genauso ein "Reset", wie ein "Reboot" (oder kann als solches verstanden/interpretiert werden) ... nur daß dabei die vorhandenen Einstellungen erhalten bleiben.
Wenn man sich hier also etwas mehr Mühe gibt und gleich selbst dafür sorgt, daß es nicht zu solchen Mißverständnissen kommen kann, macht man nicht nur "den Programmierern" den Job leichter (weil die üblicherweise auch keine Lust haben, stets dieselben Fragen beim "Nachhaken" stellen zu müssen), man erhält sich auch sein eigenes Renommee und muß sich dann nicht wundern, wieso niemand mehr auf die
abgegebenen "Fehlermeldungen" (und ich weigere mich fast, das hier:
https://github.com/Freetz-NG/freetz-ng/issues/122 so zu bezeichnen) reagiert.
