Bugreport

[Colttt]

Hallo,

ich hab in letzter Zeit ein paar Bugreports angefertigt und abgeschickt, ab wann sehe ich das sich das schonmal jmd angeguckt hat? Sind zwar nicht die besten aber besser als garnichts..

[Clio]

Soweit ich weiß, nur, wenn sich der Maintainer meldet, weil er evtl. eine Rückfrage hat.
Ich habe auf meine Bugreports nie eine Antwort bekommen.....hat vielleicht niemand interessiert....

[Colttt]

das ist natürlich richtig blöd..

da brauch man sich dann auch nicht wundern wenn man das nur einpaar mal macht und danach kein bock mehr drauf hat wenn kein feedback bekommt..

nur für die, die über mein englisch lachen wollen.. 607350 und 607810

[rendegast]

Beim ersten sind die Wackelbilder leider eine Zumutung.
Allgemeintip bei buggy-Installer des testing/squeeze:
Wenn, wie Du sagst stable/lenny einfach funktioniert, dann dieses in minimal installieren und per upgrade auf testing ziehen.




Zumindest beim zweiten report klingt es nach einer trivialen Nachfrage

Code: Alles auswählen

apt-cache rdepends mysql-common libmysqlclient16 php5-mysql

Sowas wird normalerweise nicht beantwortet.
Insbesondere auch, weil hektischerweise als "important" eingestuft.
Paßt mehr in ein Forum.

Habe nicht selbst geprüft, ob da mehr Substanz drin steckt,
aber falls sollte der bug-report spezifischer sein.

Für die Statistik kannst Du den Report selbst als gelöst anmelden,
sowas würde dann eher dankbar angenommen.

[Saxman]

Ich hab auf so ziemlich jeden meiner Bugreports antwort bekommen und in über 90% der Fälle wurde der Fehler auch lokalisiert und behoben.

Ich hab die Erfahrung gemacht dass je besser und ausführlicher der Bugreport ist, desto eher nimmt sich ein Entwickler des Fehlers an. D.h reportbug benutzen, gdb backtraces mitschicken und das richtige Paket finden dass den Fehler verursacht. Hört sich trivial an aber viele Bugs werden gegen das falsche Paket gemeldet und nicht immer kann das der Entwickler nachvollziehen. Hilfreich ist es auch im vorhinein andere Versionen des fehlerhaften Paketes zu testen um den Fehler möglichst gut einzugrenzen. Je besser der Entwickler das Problem reproduzieren kann desto eher ist die Wahrscheinlichkeit dass er sich dessen annimmt.

Was ich im übrigen auch fast immer mache ist zu überprüfen wer Upstream Betreuer des Paketes ist und mit dem setze Ich mich dann auch in Verbindung.

[Colttt]

@rendegast: guck mal hier im forum, da hab i die frage achon gestellt jedoch noch keine antwort erhalten,wurde dir gern den lin gebn aber mit handy is bissl doof
Kannst mor ja dort erklären wie ich das löse

@saxman: naja beim nächsten bugreport, evtl dann etwas besser. Aber ich hab gesehn das noch jmd das selbe problem hat mit dem langsamen installieren..

Aber danke für die hilfe und kritik an den reports ich hoffe das beim nächsten mal besser mache.. ähm wasn gdb backtraces?

[Saxman]

gdb ist der GNU Debugger. Der kann dir den Backtrace zu dem Fehler liefern.

[rendegast]

aptitude why php5-mysql
......


$ aptitude show zabbix-frontend-php
Paket: zabbix-frontend-php
Zustand: nicht installiert
Version: 1:1.8.2-1squeeze1
Priorität: optional
Bereich: net
Verwalter: Christoph Haas <haas@debian.org>
Unkomprimierte Größe: 6.300 k
Hängt ab von: debconf (>= 0.5) | debconf-2.0, apache2 | httpd, php5, php5-mysql | php5-pgsql, php5-gd, ucf, dbconfig-common (>= 1.8.19), libjs-prototype (>=
1.6.0.3), libjs-scriptaculous (>= 1.8.2), ttf-dejavu-core
Empfiehlt: zabbix-server-mysql | zabbix-server-pgsql, mysql-server (>= 4.0.16-2) | postgresql

Okay, bug-report ist insgesamt so ~ doch in Ordnung.
auch aptitude entscheidet (nach vorheriger Wahl von zabbix-server-pgsql (-> postgres))
unpassenderweise auf php5-mysql.

Jedoch sind php5-mysql / php5-pgsql nicht von den Servern abhängig,
sondern machen den Zugriff über libmysqlclient16 / libpq5.


Durch 'php5-mysql | php5-pgsql' wird das depend von zabbix-frontend-php eigentlich sauber gesetzt.
php5-mysql|-pgsql wird andererseits nicht für die eigentliche Funktion des zabbix-server-... benötigt.

Eine technische Möglichkeit wäre dann vielleicht php5-mysql|-pgsql als jeweiliges recommend des zabbix-server-...
Dann müßtest Du aber einerseits zumindest recommends akzeptieren (<-> Deine Installationsstruktur),
wäre zudem ein Eingriff in die Paketstruktur im freeze-Stadium
(würde auch dem zabbix-Server php aufbinden, obwohl das Frontend auch woanders laufen könnte),
andererseits könnte das das Problem doch nicht ganz lösen, weil ohne diese Akzeptanz das Problem weiterhin bestünde.

Die resultierende unpassende Auswahl des falschen Moduls würde der Zielgruppe des zabbix (Netzwerk-Admins) auch recht schnell auffallen (durch Nichtanzeige von Daten),
und wäre durch die Zielgruppe schnell gefixt durch entsprechende Auswahl des richtigen php-Moduls.
-> Unpassende Einstufung als "important".


Der analoge Bug ist 601831 "zabbix-frontend-php: php5-pgsql is dependency" (30-10-2010).
Deiner ist gerade 2 Tage alt.
Und obwohl beide nicht unberechtigt sind, sind sie wohl nicht lösbar,
entsprechen IMHO aber einer Art Schönheitsfehler.

Wird sich lösen, wenn postgres mysql ablöst(?) einfach dadurch, daß dann steht:
Depends: ... php5-pgsql | php5-mysql, ...
(mit einem equivs-dummy von zabbix-frontend-php ausprobiert)
Dann werden jedoch die Fans von mysql bug-reports senden



Eine Umgehung des ganzen scheint mir eine Abstufung von
Depends: ... php5-mysql | php5-pgsql, ...
zu
Suggests: php5-mysql | php5-pgsql
Dann müßte das Modul sowieso händisch ausgewählt werden.

Eine andere Möglichkeit vielleicht in einem zusätzlichen Metapaket zu php5-mysql|pgsql,
auf das sich das frontend statt auf php5-mysql|pgsql bezieht,
und das zusätzlich zu php5-mysql|pgsql direkt eine irgendgeartete Beziehung auf den jeweiligen Datenbank-Server hat.
Dann würde wohl der Zähler der richtigen Lösung steigen als "Entscheidungshilfe" für das Paketsystem-Frontend.





--------------------------
Ein wunderschönes Beispiel, wo alles paßt: 607509
Report - Reaktion - gefixtes Paket hochgeladen (sid) = 1 Tag, in testing = 3 Tage, und das im Weihnachtsstreß.

[bmario]

Zu Bug 2:

Sehr gutes Tool für alle Paketabhängigkeiten ist http://packages.debian.org
Da kannst du sehr gut suchen und deine Frage leicht klären.

So gehst du z.B. falsch herum* an die Sache heran. Nach http://packages.debian.org/squeeze/zabbix-frontend-php ist zabbix-server-mysql in den Abhängigkeiten als Recommends, du hattest dich aber schon zuvor entschieden den pgsql Server zu nehmen, also musst du dich auch kümmern, dass die anderen Abhängigkeiten passen, dann der Paketbetreuer geht von einem MySQL Server aus.

*Anmerkung: Ich meine das nicht böse, es ist natürlich ganz legitim eine Alternative Paketauswahl zu treffen, wenn dies aber entgegen der Annahmen der Paketbetreuer ist, heißt das halt für dich mehr Nachkontrolle. Genauso ist es mit Metapaketen. Du musst sie nicht nutzen, wenn sie nicht deinen Kriterien entsprechen, aber dann bitte nicht beschweren, dass du mehr Arbeit hast.

[rendegast]

der Paketbetreuer geht von einem MySQL Server aus.

Nach Deinem eigenen Beispiel:

php5-mysql
MySQL module for php5
or php5-pgsql
PostgreSQL module for php5

mysql-server (>= 4.0.16-2)
MySQL database server (metapackage depending on the latest version)
also a virtual package provided by mysql-server-5.1
or postgresql
object-relational SQL database (supported version)

zabbix-server-mysql
network monitoring solution - server (using MySQL)
or zabbix-server-pgsql
network monitoring solution - server (using PostgreSQL)

Resp.

Depends: debconf (>= 0.5) | debconf-2.0, apache2 | httpd, php5, php5-mysql | php5-pgsql, ...
Recommends: zabbix-server-mysql | zabbix-server-pgsql, mysql-server (>= 4.0.16-2) | postgresql

Nur weil dann innerhalb dieses 'or' die Position priorisiert wird, gelangt hier das unpassende php5-mysql zum Zuge.
Dieses 'or' jedoch noch mit einer Art Umgebungstest auszustatten wäre wohl zuviel Aufwand
und läßt sich mit ein wenig Nachdenken und Erfahrung ja auch so lösen.

[TuxPeter]

Hallo,
vielleicht passt meine Frage / Anmerkung genau in diesen Thread:

Ich habe synaptic unter squeeze (mit apt-get) installiert, welches sich zwar korrekt installierte und auch ins Menü von xfce4 eintrug, aber nicht startete. Der Grund ist nicht schwer zu finden. Synaptic wird zwecks root-Abfrage mit einem kleinen script namens su-to-root gestartet
("su-to-root -X -c /usr/bin/synaptic") Dieses fehlte, ließ sich aber leicht vom parallel installierten Lenny kopieren.

Wem nun kann ich denn diese Information sinnvollerweise zukommen lassen? Den im Synaptic genannten doch wohl kaum, ist ja kein Fehler in synaptic. Es scheint auch so, daß das Script für nichts anderes gebraucht wird.

Grüße, TuxPeter

[bmario]

So hätte man auch gewusst, was zu tun ist...
http://packages.debian.org/search?searc ... g&arch=any

Außerdem benötigst du gksu, wenn du Synaptic aus dem Menü starten willst. Und nein, es passt hier nicht rein.

[rendegast]

Mein Link ist schöner:
http://packages.debian.org/file:su-to-root -> Paket menu

[TuxPeter]

Auch wenn es nicht reinpasst: Danke an rendergast und bmario für die Antworten. Habe halt an den falschen Stellen gesucht, nämlich nach den und nicht in den Paketen - wieder was gelernt.
Außerdem benutzt xfce4 nicht menu sondern libxfce4menu-0.1.0, folglich erscheint es nicht sonderlich sinnvoll, auch noch menu zu installieren. (gksu war schon da und ist ein eigenes Paket)

Grüße, TuxPeter

[Colttt]

kann mir jmd sagen was das bedeutet:


heisst das dieser Bug im 2.6.32-30 behoben werden soll??

[hikaru]

Wäre eine Bugreport-Review-Sektion im Forum sinnvoll, in der man erstmal Bugreports zur Diskussion stellt bevor man sie wirklich abschickt?

Mein erster Bugreport ist z.B. dieser hier:
578546

Mittlerweile weiß ich, dass ich ihn falsch plaziert habe (weil gegen bpo-Kernel). Besser wäre es gewesen direkt 2.6.32 aus Squeeze (das ich damals noch nicht installiert hatte, sich aber genauso verhält wie ich inzwischen weiß) zu testen und dagegen den Bugreport zu stellen. Hätte ich sonst noch was besser machen können?

[deberik]

heisst das dieser Bug im 2.6.32-30 behoben werden soll??

Nein. Das heißt, dass der Fehler in Version 2.6.32-30 immer noch vorhanden ist (bzw. nicht explizit korrigiert wurde). Wenn er behoben wird, dann sind die korrigierten Versionen grün eingefärbt, etwa so:



Grüße,
Erik