After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 353250 - issues with some of the guesswork done by bug-buddy
issues with some of the guesswork done by bug-buddy
Status: RESOLVED WONTFIX
Product: bug-buddy
Classification: Deprecated
Component: general
2.15.x
Other Linux
: Normal normal
: ---
Assigned To: Bug-buddy Maintainers
Bug-buddy Maintainers
gnome[unmaintained]
: 493210 (view as bug list)
Depends on:
Blocks: 352989
 
 
Reported: 2006-08-28 14:41 UTC by Matthias Clasen
Modified: 2018-07-16 08:24 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Clasen 2006-08-28 14:41:21 UTC
Right now, bug-buddy in rawhide does not know how to file evolution bugs.
That is because evolution sets its prgname to evolution-2.8, but the desktop
file calls it via a symlink called just evolution. We can work around that by
making evolution set its prgname to 'evolution'. But playing with this problem
made a few more problems show up:

1) The bug-buddy report calls the application 'Calendar'. This is because
   we install multiple desktop files which execute evolution with different
   commandline options, and the calendar one happens to be the first one.  

2) When I renamed the evolution binary from 'evolution-2.8' to 'evolution',
   bug-buddy suddenly claimed that the stacktrace was generated by
   '/usr/libexec/evolution-2.8', which is utter nonsense.

   Deriving this information from desktop files or guessing that it must be
   an applet in /usr/libexec seems to fragile. 
   It would be more robust to to get both the appname (set with 
   g_set_application_name) and the path to the binary (just argv[0]) from
   inside the crashed process, and pass them along to gnome_segv.
Comment 1 Matthew Barnes 2006-08-28 14:53:44 UTC
Harish, Srini: You guys should be aware of this.
Comment 2 Fernando Herrera 2006-12-02 16:27:55 UTC
what about using the pid for reading the /proc/$pid/exe ?
Comment 3 Fernando Herrera 2006-12-13 17:39:27 UTC
For the evolution case, the .desktop file could include something like:
Exec=evolution
X-GNOME-Bugzilla-OtherBinaries=evolution-2.8

I agree with the path issue, however there is a problem that I don't know how to solve: when we have different .desktop files for the same binary, like Evolution (mail, calender), nautilus (browser, cd-burner). We could extend the bug-buddy hash table mapping to include the arguments specified on the .desktop file for those applications, and then,when the key (binary name) is dupplicated we could compare /proc/$pid/cmdline with those arguments. However most of these applications are single instance one, so it doesn't matter if we invoke "nautilus --no-desktop burn:///", because the crashing proccess args (the ones that we would get either from argv[0] either from /proc) would be still the ones from the original proccess. 
Comment 4 Cosimo Cecchi 2008-09-25 14:57:07 UTC
*** Bug 493210 has been marked as a duplicate of this bug. ***
Comment 5 André Klapper 2018-07-16 08:24:28 UTC
bug-buddy is not under active development anymore and had its last code changes
many years ago. Its codebase has been archived:
https://gitlab.gnome.org/Archive/bug-buddy/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality (see bug 796784). Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.