staging.inyokaproject.org

Der Befehl ist fehlerhaft! Es muss heißen

ubuntu-bug -p (Paketname)

und

ubnutu-bug -P (Prozess-ID)

. Jedenfalls war das bei meinem Hardy so.

@1: Der Schalter muss anscheinend mit einer neueren Version rausgefallen sein, denn unter Jaunty lautet der Befehl so wie angegeben. Apport Version: 0.146

Falls das jemand mit der Hardy-Version von Apport bestätigen kann, werde ich den Artikel dahingend updaten...

Ich habe nun mehrmals mit Aport fehler "sammeln" lassen und diese auch hoch geladen.

Immer jedoch, wenn ich dann den Bug in Lauchpad hinzufügen will, scheint der eigentliche "Fehlerbericht" der durch Aport erstellt wurde zu fehlen. So muss ich trotzdem alle möglichen Informationen hinzufügen. (Version des OS oder "wie kam es zum absturz", etc). Ausserdem sehe ich nirgends einen Anhang an meinen Bugreport, welcher der "Fehlerbericht" sein könnte. Ich kann gerne mal ne Screenshot-tour machen. Wenn das Problem aus meinen paar Sätzen nicht hervorgeht.

Bilder sagen ja bekanntlich mehr als tausend Worte.

Grüße H.i.M

@3: Kann ich nicht bestätigen, ich habe erst heute mit Apport von Jaunty einen Bugreport erstellt und er hat alle nötigen Dateien angehangen.

Gruß, Stefan

@4: vlt liegt es daran, dass ich KUbuntu nutze?

@all: kann das jmd. der Kubuntu nutzt bestätigen? Ich werde das noch mal testen und ggf. Screenshots machen.

Grüße H.i.M

Ist es normal, dass Apport schon installiert ist?

@5: Ne, bei mir funzt es.

@6: Muss wohl, war bei mir auch schon da.

Was mich stutzig macht, ist, dass apport-qt root-Rechte braucht. Das kommt mir wirklich spanisch vor.

Bitte baut auch noch einen Link zu Fehler melden ein ☺ Dort steht das alles ausführlich beschrieben mit vielen anderen Tipps.

Ich kann bestätigen, dass unter Hardy der Befehl

ubuntu-bug -p (Paketname)

bzw. der Befehl

ubuntu-bug -P (Prozess-ID)

richtig ist!

Danke an ubuntufreak und steinson für den Hinweis mit dem Befehl ubuntu-bug.

Danke an Chrissss für die Wikiseite.

Habe beides eingebaut.

Ach noch ein kleiner Hinweis: wenn eine Anwendung crasht, dann bitte nur den Bug reporten, wenn ihr die entsprechenden -dbg Pakete installiert habt. Ansonsten bringt der Backtrace nämlich rein gar nichts.

Wenn man also beispielsweise einen Crash unter KDE von Plasma hat, dann ist der Backtrace erst einmal nutzlos. Das korrekte Vorgehen ist dann, das passende dbg Paket zu installieren (kdebase-workspace-dbg) und den Crash zu reproduzieren. Nun hat man einen Backtrace der nützlich ist.

Ein Backtrace ohne vorherige Installation der debug Pakete sagt den Entwicklern nur, dass etwas abgestürzt ist, aber nicht wo.

Das mit den fehlenden -dbg Paketen ist ein Problem. In der Regel installiert die ja niemand, und oft passiert ein Fehler eben so, dass man ihn nicht wieder provozieren kann. In solchen Fällen kann also kein vernünftiger Bug-Report erstellt werden.

Eigentlich sollten mit den Testversionen von Ubuntu zu jedem Paket auch automatisch die zugehörigen -dbg Pakete installiert werden. Wenn dann das Release heraus ist, sollte es im Paketmanager eine Option geben, alle -dbg Pakete wieder zu entfernen.

Vermutlich gibt es derzeit keinen Zusammenhang zwischen Paket und seinem -dbg-Paket, ausser dem Namenszusatz? Wenn also der Paketmanager wüsste, dass kdebase-workspace-dbg das Debug Paket zu kdebase-workspace ist, dann könnte man eine folgende Optionen in den Paketmanager integrieren:

• Debug-Pakete anzeigen/installieren

• Debug-Pakete entfernen

Oder gibt es sowas schon?

Wie geht man vor, wenn man nicht weiss wo die Ursache liegt? Welches paket das problem ist?

Mein (durchaus auch amüsantes) Beispiel: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/324506 Lest mal meine erste Ergänzung (Die Liste) 🙄

@11: Wie kann man denn eigentlich vorgehen, wenn sich der Fehler erst mal nicht reproduzieren lässt?

Bringt dann die Installation der dbg-Pakete, die man für ursächlich hält, weitere Erkenntnisse für den Fall, dass der Fehler dann später wieder irgendwann auftritt?

Gruß, Martin

Gute Bugreports zu erstellen ist eine Kunst. Einen Bug und/oder Crash, welchen man nicht reproduzieren kann, zu melden macht meiner Meinung nach keinen Sinn, weil die Entwickler den Bug/Crash dann auch nicht reproduzieren können. Solche Bugs überfluten leider die Bugtracker der OpenSource Projekte und behindern zum Teil die Entwickler eher als ihnen zu helfen. Daher setzen viele Projekte auch Bug Squads ein.

Daher sollte man immer, wenn man einen Crash reporten möchte, die dbg Pakete installieren und versuchen den Crash zu reproduzieren. Hat man die dbg Pakete installiert und der Crash tritt auf ohne dass man weiß wie man den Crash reproduziert, kann man den Bug auch aufmachen, da nun anhand des Stacktraces die Entwickler sehen können, was den Crash verursacht. Also welche Bedingungen vorlagen und daraus können sie schlußfolgern, wie sie ihn reproduzieren können.

Also noch mal zusammengefasst für einen Crash: entweder einen guten Stacktrace mit dbg-Paketen oder mindestens eine Beschreibung, wie man den Crash reproduzieren kann. Wobei man in diesem Fall auch den Crash reproduzieren kann mit dbg-Paketen.

@15: Wie sollen wir also damit umgehen, wenn aport uns einen Fehler meldet? Sollen wir es unkommentiert senden, was es da so sammelt und dann den bereits gemeldeten Bug unterzeichen, bzw. einen neuen (privaten) erstellen?

LG H.i.M

PS: übrigens hat aport heute das allererste mal bei mir funktioniert. Nach dem Senden und Erstellen des Bugs, hat er die gesammelten Dateien tatsächlich doch mal hinzugefügt. Eigentlich "schade", weil ich mein "Problem" gerne reproduzieren wollte.(Hatte heute schon angefangen Screenshots zu machen....

@16: wenn sich apport so verhält wie DrKonqui in KDE, dann besser den Bericht nicht senden, da es nichts bringt. Das richtige Vorgehen, ist die dbg Pakete zu installieren und anschließend den Crash erneut zu erzeugen und erst dann den von Apport gemeldeten Crash melden.

Ich hab das auch so in Fehler melden eingetragen.

Einen Bug und/oder Crash, welchen man nicht reproduzieren kann, zu melden macht meiner Meinung nach keinen Sinn, weil die Entwickler den Bug/Crash dann auch nicht reproduzieren können. Solche Bugs überfluten leider die Bugtracker der OpenSource Projekte und behindern zum Teil die Entwickler

Dann wärs doch am praktischsten, wenn man nur reproduzierbare Fehler einschicken kann.

"Bitte schicken Sie nur Fehler ein, die bei Ihnen mind. 2 mal aufgetreten sind." sollte Ubuntu sagen, wenn man gerade einen Bugreport verschicken will.

Btw: Unter Windows hat mich die Frage "Ihr Programm ist abgestürzt. Wollen Sie Microsoft einen Fehlerbericht" immer genervt, aber für Ubuntu würde ich so gerne Fehler verschicken. Gibts diese Möglichkeit eigentlich (schon) ? Noch besser wäre es ja, wenn Ubuntu automatisch erkennen würde, ob der Fehler schon zum 2. Mal aufgetreten ist.

Ich will das nicht als Pflichteinstellung haben, aber so für Freiwillige fände ich das nicht schlecht.

@18: Der Artikel Fehler melden nennt in der Rubrik "Wann soll ein Bug gemeldet werden?" breits, dass der Fehler reproduzierbar sein muss.

Ja, Apport unterstützt das direkte senden eines Bugreports wenn die Anwendung abgestürzt ist. Unter Ubuntu gibt es auch in vielen Anwendungen im Menü Hilfe einen Eintrag um einen Bug zu reporten.

Bei Kubuntu führt dieser Eintrag auf den KDE Bugtracker anstatt auf Launchpad.

Hallo,

bei meinem Xubuntu 9.04 war bei der Alpha 6 auch immer irgendwas abgestürzt und Apport meldete sich. Natürlich wollte ich den Bericht absenden, weil ich dachte das dieser automatisch wie bei Microsoft gesendet wird.

Das Tool macht aber nur Launchpad auf und man muss sich dort einloggen bzw. erst mal anmelden. Das ist wenig Nutzerfreundlich, vor allem weil noch wollte das ich irgendwelche Kategorien auswähle.

Warum werden die Berichte von Apport nicht gesondert gespeichert, ohne das der Benutzer sich irgendwo anmelden und irgendwelche Daten eingeben muss?

@19: Das sollte aber meiner Meinung nach so einfach sein, dass man nicht ins Wiki kucken muss und generell glaube ich, dass einige vll. nicht ins Wiki schauen. Gibt ja noch andere Quellen.

@21: ja da stimme ich zu. Das Problem ist recht einfach: Pakete mit debug Informationen sind riesig. Für das komplette System wären das mehrer Gigabyte zusätzlich. Nicht akzeptabel das mitzuliefern (denk mal nur an Nutzer mit einer Modem-Verbindung). Ohne die Debug Pakete sind die Crash Reports aber nutzlos. Es ist eine Abwägung. KDE's Crash Report Tool zeigt nun an, dass in einem solchen Fall der Report nicht zu gebrauchen ist und nutzlos ist.

Man muss auch berücksichtigen, dass die Mail, welche hier den Artikel motivierte an Entwickler ging, die natürlich die Problematik kennen und daher ist - denke ich - das Problem in der Mail auch nicht angesprochen.

Also ich muss sagen , das lp. wo man sich erst Regestriere muss , um einen bug zu melden ist wirklich sch,,,, . Wenn bei mir abstürze kahmen habe ich sie nie gemeldet weil das einfach zu umständlich ist . Apport sollte standart sein ☺

@22 Mehrere GB ? ist doch kein Proplem , auch für kleine leitungen nicht. Da solte der anwender eine upload beschränkung eintragen können und dan das ganze "paket" in mehrere chunks aufteilen ☺ Alla filesharing ☺

Wenn ich mich nicht irre braucht man nichtmal die dbg-Pakete. Man kann nachträglich aus dem Backtrace mittels der DBG-Pakete die Code-Zeilen ermitteln und afaik macht das Apport auch nach dem der Backtrace hochgeladen wurde. Das so genannte retracing. Teilweise dauert das aber über 24 Stunden, wenn der Server ausgelastet ist.

@24: das ist natürlich erfreulich.