Re: bug-buddy integration
On Thu, 12 Mar 2009 10:21:07 +0100, Frederic Crozat fcro...@mandriva.com wrote: Le mercredi 11 mars 2009 à 17:07 -0700, Max Kanat-Alexander a écrit : And Mozilla has Soccoro, which is a web frontend for Breakpad: http://crash-stats.mozilla.com/ http://code.google.com/p/socorro/ Which is used in latest version of bug-buddy and known to be broken on build.gnome.org because nobody has time to maintain it :( crash.gnome.org What I understand from [1] is that the work resides here git-clone http://www.gnome.org/~fherrera/dumper.git git-clone http://www.gnome.org/~fherrera/socorro.git git-clone http://www.gnome.org/~fherrera/bug-buddy.git and that we need to setup ... package collectors: a simple piece of code that has to: * Download all packages from a distro * Check for updates and download them * Extract binaries from those packages onto a temporal directories * Feed those packagers to our symbolsuplier No idea how many hours this might take. [1] http://www.gnome.org/~fherrera/blog/2007/Sep/30#breakpad -- Christian Kirbach ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Slight side topic question here... for gnome 2.24, GTK_MODULES was set to include gnomebreakpad on session login depending on whether /usr/lib/gtk-2.0/modeules/libgnomebreakpad.so existed or now. Removing gnomebreakpad from GTK_MODULES env variable resulted in bug-buddy not being invoked. I've noticed on 2.26 that gnomebreakpad appears to be getting loaded regardless of what GTK_MODULES contains... is this intentional ? is there any way of stopping this happening other than actually removing the library ? Matt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Le vendredi 20 mars 2009, à 16:15 +, Matt Keenan a écrit : Slight side topic question here... for gnome 2.24, GTK_MODULES was set to include gnomebreakpad on session login depending on whether /usr/lib/gtk-2.0/modeules/libgnomebreakpad.so existed or now. Removing gnomebreakpad from GTK_MODULES env variable resulted in bug-buddy not being invoked. I've noticed on 2.26 that gnomebreakpad appears to be getting loaded regardless of what GTK_MODULES contains... is this intentional ? is there any way of stopping this happening other than actually removing the library ? I guess this would help: /apps/gnome_settings_daemon/gtk-modules/gnomebreakpad Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Ahhh... merci beaucoup :) On 20/03/2009 16:33, Vincent Untz wrote: Le vendredi 20 mars 2009, à 16:15 +, Matt Keenan a écrit : Slight side topic question here... for gnome 2.24, GTK_MODULES was set to include gnomebreakpad on session login depending on whether /usr/lib/gtk-2.0/modeules/libgnomebreakpad.so existed or now. Removing gnomebreakpad from GTK_MODULES env variable resulted in bug-buddy not being invoked. I've noticed on 2.26 that gnomebreakpad appears to be getting loaded regardless of what GTK_MODULES contains... is this intentional ? is there any way of stopping this happening other than actually removing the library ? I guess this would help: /apps/gnome_settings_daemon/gtk-modules/gnomebreakpad Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
top-post don't Please On Fri, Mar 20, 2009 at 5:55 PM, Matt Keenan matt.kee...@sun.com wrote: Ahhh... merci beaucoup :) On 20/03/2009 16:33, Vincent Untz wrote: [...] ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Thu, 12 Mar 2009 00:42:12 +0100, Luis Villa l...@tieguy.org wrote: On Wed, Mar 11, 2009 at 7:28 PM, Brian Nitz brian.n...@sun.com wrote: Luis Villa wrote: - optionally passes bug first to a distribution maintained bug database. (to filter distro specific bug pollution) This is the default behavior distros tend to want... which makes it hard for upstream to do anything useful, since the distros are historically pretty bad at getting this data upstream. (By 'pretty bad' I don't think any distro which does this has ever systematically/programatically moved that data upstream, though I'm certainly out of touch and may have missed something.) I am not sure about the current status of this upstream pushing work. I did intensive triaging work up to the Gnome 2.22.x cycle. I remember Sebastien Bacher manually pushed quite some downstream (Ubuntu) reports to us, and all those came with excellent debugging traces. Saw this occassionally from Gentoo, too. However I do not remember this from any other of the big distros. It would be helpful if someone could give us a brief outline of the different reporting systems distros are currently using. We may want to pick the best cherries and adopt them. We should do more collaboration here. -- Christian Kirbach ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Thu, 2009-03-12 at 10:21 +0100, Frederic Crozat wrote: [Breakpad / Socorro / Crash catcher] Which is used in latest version of bug-buddy and known to be broken on build.gnome.org because nobody has time to maintain it :( At one point bug-buddy generated a stack trace and sent it to b.g.o (or to bugzilla.distro.org as per-distro patches). With those stack traces, you were either able to fix the bug, or start diagnosing it, or at least you could tell the submitter, please install debuginfo for this dependency as I need to see what's going on there. Currently, bug-buddy doesn't send a stack trace, so what it sends is useless. In such bug reports, you must always ask the submitter, please get a stack trace with all the trouble that explaining that entails. Why don't we just revert to the old version of bug-buddy? It required no upstream or downstream maintenance to *keep it working*, that is, to be producing stack traces automatically. In the new bug-buddy, the default is it doesn't work. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Am Freitag, den 13.03.2009, 15:13 -0600 schrieb Federico Mena Quintero: Currently, bug-buddy doesn't send a stack trace Why do you assume bug-buddy does not send a stacktrace? My bug-buddy did send a stacktrace a few days ago, otherwise I wouldn't have been able to submit gnome bug 575009. In such bug reports, you must always ask the submitter, please get a stack trace with all the trouble that explaining that entails. A stock answer linking to http://live.gnome.org/GettingTraces explaining everything(tm) is just one click away. If that wikipage is unclear everyone is invited to edit/improve it. In the new bug-buddy, the default is it doesn't work. I can't second this. In fact the new (whatever that means) bug-buddy has reduced bugsquad workload by e.g. rejecting many useless traces already before they get submitted to gnome bugzilla. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Le mercredi 11 mars 2009 à 17:07 -0700, Max Kanat-Alexander a écrit : On Wed, 11 Mar 2009 23:46:43 +0100 Andre Klapper ak...@gmx.net wrote: Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki And Mozilla has Soccoro, which is a web frontend for Breakpad: http://crash-stats.mozilla.com/ http://code.google.com/p/socorro/ Which is used in latest version of bug-buddy and known to be broken on build.gnome.org because nobody has time to maintain it :( -- Frederic Crozat fcro...@mandriva.com Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Le mercredi 11 mars 2009 à 19:42 -0400, Luis Villa a écrit : - capture more complete distro and component revision information. This is pretty complete in modern versions of bug-buddy, I believe. Clearly not. Compared to reportbug, which brings information about kernel revision, APT policy, dependencies and related packages, reports generated by bug-buddy are far from there. The code to gather this information is already here but it is distribution-specific, so what we need is just a hook. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Le jeudi 12 mars 2009 à 10:21 +0100, Frederic Crozat a écrit : Le mercredi 11 mars 2009 à 17:07 -0700, Max Kanat-Alexander a écrit : On Wed, 11 Mar 2009 23:46:43 +0100 Andre Klapper ak...@gmx.net wrote: Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki And Mozilla has Soccoro, which is a web frontend for Breakpad: http://crash-stats.mozilla.com/ http://code.google.com/p/socorro/ Which is used in latest version of bug-buddy and known to be broken on build.gnome.org because nobody has time to maintain it :( I mean crash.gnome.org, not build.gnome.org -- Frederic Crozat fcro...@mandriva.com Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On 11/03/2009 13:56, Jonh Wendell wrote: Hi, folks. We from Brazilian team are discussing about the best option to report bugs related with translations. An optimal solution is to have bug-buddy integrated into applications, in the menu Help-Report a bug or wish. This would call bug-buddy, the user would select the severity of the bug (translation, bug, suggestion), enter the bug itself and then would hit the 'send' button. Simple like that. Ubuntu does something similar, but the negative points are: - Ubuntu packagers have to patch lots of applications; - The bug reports go to launchpad, ubuntu only; - The launchpad interface is English-only, where bug-buddy is translated into the user language; Perhaps bug-buddy could be configurable to send reports to another place instead of only bugzilla.gnome. I know this is something (Sun), are definitely interested in and are looking into. We'd like bug-buddy to send reports to OpenSolars bugzilla (defects.opensolaris.org). Configureable bug database a definite plus. Matt Ideas? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, Mar 11, 2009 at 2:56 PM, Jonh Wendell jwend...@gnome.org wrote: Hi, folks. Hi :-) We from Brazilian team are discussing about the best option to report bugs related with translations. An optimal solution is to have bug-buddy integrated into applications, in the menu Help-Report a bug or wish. This would call bug-buddy, the user would select the severity of the bug (translation, bug, suggestion), enter the bug itself and then would hit the 'send' button. Simple like that. Ubuntu does something similar, but the negative points are: - Ubuntu packagers have to patch lots of applications; - The bug reports go to launchpad, ubuntu only; - The launchpad interface is English-only, where bug-buddy is translated into the user language; Well. actually it is not exactly like that. Ubuntu has two menu entries for the help on each app to report things. * Report an error (apport) * Translate the application The error report is what you describe, but I think it's a bit better than you said. Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. It does generate very complete reports and send them as a Multipart/MIME so the server side can receive each log as a different attachment, which is very clear. It's made in python and is easy to add hooks[2] for applications to attach more logs or info to the report. And the tool is translated into several languages: http://translations.launchpad.net/ubuntu/jaunty/+source/apport/+pots/apport Anyways, this is very focused in crash or issues report. The other option takes you to the Ubuntu translation page for that application. But I guess it's just good for the Ubuntu translators, because it's not very easy for normal (non-English speaker) user to find how to fill a translation bug. We could redirect the user to a translation bug for the product of the application in our Bugzilla. Something like: http://bugzilla.gnome.org/simple-bug-guide.cgi?sbg_type=l10nproduct=l10napplication=hamster-appletcomp=Spanish [es] If I'm launching it from hamster-applet with Spanish locales. Perhaps bug-buddy could be configurable to send reports to another place instead of only bugzilla.gnome. I don't know how is now bug-buddy, but I remember that before was a bit hard for a newbie of non very tech people. Maybe now it's is more user friendly... Anyway, this is an interesting thing and wold be nice to have such a feature :-) Cheers [1] https://wiki.ubuntu.com/Apport [2] https://wiki.ubuntu.com/Apport/DeveloperHowTo -- Juanje ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, Mar 11, 2009 at 6:46 PM, Andre Klapper ak...@gmx.net wrote: Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. No need to wonder; it definitely is duplicated and wasted effort. Not intentional, of course[1], but painful no matter how you slice it. Luis [1] Despite the slight tinge of NIH in many of the efforts. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Luis Villa wrote: On Wed, Mar 11, 2009 at 6:46 PM, Andre Klapper ak...@gmx.net wrote: Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. No need to wonder; it definitely is duplicated and wasted effort. Not intentional, of course[1], but painful no matter how you slice it. Luis [1] Despite the slight tinge of NIH in many of the efforts. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Do we have a list of features missing from bug buddy so maybe we could direct some of this energy towards making it (or some standard community crash logger) meet community need and distro specific needs so we don't have every distro reinventing this wheel? My own ideas are: - capture more complete distro and component revision information. - optionally passes bug first to a distribution maintained bug database. (to filter distro specific bug pollution) - callable by user from application (window manager?) menu, captures user comments as well as application context info. - plug-ins for distro specific capture tools (strace, ktrace, truss, dtrace, mdb, pstack, gdb, dbx,...) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Thu, Mar 12, 2009 at 12:28 AM, Brian Nitz brian.n...@sun.com wrote: Do we have a list of features missing from bug buddy so maybe we could direct some of this energy towards making it (or some standard community crash logger) meet community need and distro specific needs so we don't have every distro reinventing this wheel? I strongly believe we need two applications. A kernel-level crash logger (like apport) and a bug submitting tool like bug-buddy. The easiest way would be to make bug-buddy read apport's (or any other kernel crash logger's) format. Please note that since apport is system-wide (not user-specific and not limited to GNOME or even X11 apps) it cannot interact with bag-buddy directly. It also can't be adapted to use GNOME's format as KDE guys and (more importantly) system admins still need to be able to access the data. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, Mar 11, 2009 at 7:28 PM, Brian Nitz brian.n...@sun.com wrote: Luis Villa wrote: On Wed, Mar 11, 2009 at 6:46 PM, Andre Klapper ak...@gmx.net wrote: Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. No need to wonder; it definitely is duplicated and wasted effort. Not intentional, of course[1], but painful no matter how you slice it. Do we have a list of features missing from bug buddy so maybe we could direct some of this energy towards making it (or some standard community crash logger) meet community need and distro specific needs so we don't have every distro reinventing this wheel? My own ideas are: - has to work with non-GNOME apps. - capture more complete distro and component revision information. This is pretty complete in modern versions of bug-buddy, I believe. - optionally passes bug first to a distribution maintained bug database. (to filter distro specific bug pollution) This is the default behavior distros tend to want... which makes it hard for upstream to do anything useful, since the distros are historically pretty bad at getting this data upstream. (By 'pretty bad' I don't think any distro which does this has ever systematically/programatically moved that data upstream, though I'm certainly out of touch and may have missed something.) Mind you, it isn't clear to me that upstream has been doing much useful with the data we do have of late, but like the uncoordinated re-inventions of bug-buddy, that is a symptom of the general underinvestment in QA by GNOME partners. - callable by user from application (window manager?) menu, captures user comments as well as application context info. - plug-ins for distro specific capture tools (strace, ktrace, truss, dtrace, mdb, pstack, gdb, dbx,...) I'd note that this data is actually overrated. Useful, yes, but even the primitive information we used to get was very useful when we got it in volume and we had eyes poring over it for clues. I have a sense that the current emphasis on all these various tools (with their attendant complexities) makes perfect data collection the enemy of good data collection. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, 11 Mar 2009 23:46:43 +0100 Andre Klapper ak...@gmx.net wrote: Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki And Mozilla has Soccoro, which is a web frontend for Breakpad: http://crash-stats.mozilla.com/ http://code.google.com/p/socorro/ -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
Luis Villa wrote: On Wed, Mar 11, 2009 at 7:28 PM, Brian Nitz brian.n...@sun.com wrote: Luis Villa wrote: On Wed, Mar 11, 2009 at 6:46 PM, Andre Klapper ak...@gmx.net wrote: Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. No need to wonder; it definitely is duplicated and wasted effort. Not intentional, of course[1], but painful no matter how you slice it. Do we have a list of features missing from bug buddy so maybe we could direct some of this energy towards making it (or some standard community crash logger) meet community need and distro specific needs so we don't have every distro reinventing this wheel? My own ideas are: - has to work with non-GNOME apps. I don't think this precludes having a user-invoked option, though it does make it a bit more of a challenge. - capture more complete distro and component revision information. This is pretty complete in modern versions of bug-buddy, I believe. - optionally passes bug first to a distribution maintained bug database. (to filter distro specific bug pollution) This is the default behavior distros tend to want... which makes it hard for upstream to do anything useful, since the distros are historically pretty bad at getting this data upstream. (By 'pretty bad' I don't think any distro which does this has ever systematically/programatically moved that data upstream, though I'm certainly out of touch and may have missed something.) Mind you, it isn't clear to me that upstream has been doing much useful with the data we do have of late, but like the uncoordinated re-inventions of bug-buddy, that is a symptom of the general underinvestment in QA by GNOME partners. Too true. - callable by user from application (window manager?) menu, captures user comments as well as application context info. - plug-ins for distro specific capture tools (strace, ktrace, truss, dtrace, mdb, pstack, gdb, dbx,...) I'd note that this data is actually overrated. Useful, yes, but even the primitive information we used to get was very useful when we got it in volume and we had eyes poring over it for clues. I have a sense that the current emphasis on all these various tools (with their attendant complexities) makes perfect data collection the enemy of good data collection. I agree that too much information in the capture can be at least as much of a problem as too little. Still, it would be nice to capture enough to have a unique 'bug/crash fingerprint'. Everyone tells me this is impossible, but I'm an optimist. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, Mar 11, 2009 at 8:53 PM, Brian Nitz brian.n...@sun.com wrote: - plug-ins for distro specific capture tools (strace, ktrace, truss, dtrace, mdb, pstack, gdb, dbx,...) I'd note that this data is actually overrated. Useful, yes, but even the primitive information we used to get was very useful when we got it in volume and we had eyes poring over it for clues. I have a sense that the current emphasis on all these various tools (with their attendant complexities) makes perfect data collection the enemy of good data collection. I agree that too much information in the capture can be at least as much of a problem as too little. Still, it would be nice to capture enough to have a unique 'bug/crash fingerprint'. Everyone tells me this is impossible, but I'm an optimist. To be clear, it isn't that I object to the extra information; it is terrific if you can get it. It's just that if I could choose between a system that gets me low-quality data tomorrow, or high-quality data 2-4 release cycles from now, I'd choose the timely low-quality data in a heartbeat, and I think that many other people are instead opting for the latter because they believe the low-quality data is not useful. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
