Bug 202289

Summary: doesn't recognize evolution
Product: [Fedora] Fedora Reporter: Matthias Clasen <mclasen>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-08 03:38:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150223    
Attachments:
Description Flags
Patch to apply the change described in comment #2 none

Description Matthias Clasen 2006-08-12 06:33:38 UTC
bug-buddy claims to not know how to file evolution bugs. Thats unfortunate,
since evolution crashes a lot...

I suspect the problem may be that the evolution process is using the binary
evolution-2.8, while the .desktop files all list evolution (without the -2.8)

Comment 1 Matthias Clasen 2006-08-28 05:08:20 UTC
ok, so looking through this tangled weave, bug-buddy seems to get the
application name indirectly from g_get_prgname(), and this seems to be set to
"evolution-2.8"
in evolution by passing this string to gnome_program_init() as app_id.

Can I propose that we 

a) don't install an evolution-2.8 binary with an evolution symlink, but just
   an evolution binary

b) pass the string "evolution" to gnome_program_init

Comment 2 Matthew Barnes 2006-08-28 11:27:35 UTC
In evolution/shell/main.c we have:

    program = gnome_program_init (PACKAGE "-" BASE_VERSION, ...);

To satisfy part (b) we could just change it to:

    program = gnome_program_init (PACKAGE, ...);

Is part (a) then really necessary for bug-buddy to behave correctly?
(Just trying to avoid messing with Makefiles if there's an easier way.)

Comment 3 Matthew Barnes 2006-08-28 11:41:14 UTC
A separate bug related problem is that bug-buddy seems to think that the
human-readable name of the package "evolution" is Calendar.

   $ bug-buddy --package=evolution

   Thank you for helping us improving our software.
   Please fill your suggestions/error information for Calendar
   application.

I'm guessing this is because it's scanning .desktop files looking for the first
entry that invokes "evolution", and we have separate menu items for each
Evolution component.  Calendar just happens to come first.

   $ grep evolution /usr/share/applications/* | head -n1
   redhat-evolution-calendar.desktop:Exec=evolution --component=calendar

   $ grep Name= /usr/share/applications/redhat-evolution-calendar.desktop
   Name=Calendar

Comment 4 Matthew Barnes 2006-08-28 12:40:37 UTC
This needs to be a separate bug report, but just wanted to follow up on my last
comment with a brain storm.  If bug-buddy can extract the program name
indirectly from g_get_prgname(), could it not also extract the human-readable
application name indirectly from g_get_application_name()?  The application name
in GLib should be localized, so maybe bug-buddy wouldn't have to go sifting
through .desktop files at all.

I'll investigate this.

Comment 5 Matthias Clasen 2006-08-28 13:48:41 UTC
That'll be more work, since the data is collected in the libgnomui segv_setup
function, and then passed to gnome_segv, which passes it on to bug-buddy

Comment 6 Matthias Clasen 2006-08-28 13:50:01 UTC
Regarding the binary name, thats probably not necessary. The important part is
that g_get_ptrname returns the same name that is in the .desktop file.

Comment 7 Matthias Clasen 2006-08-28 14:43:42 UTC
I've filed an upstream bug about related bug-buddy issues here: 
http://bugzilla.gnome.org/show_bug.cgi?id=353250

Comment 8 Matthew Barnes 2006-08-28 17:24:35 UTC
Created attachment 135058 [details]
Patch to apply the change described in comment #2

This should be in tomorrow's Rawhide as evolution-2.7.92-6.fc6.

Comment 9 Matthias Clasen 2006-09-08 03:38:34 UTC
Seems to work for me.