[example for gnome-calculator .desktop file]

X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=gcalctool
X-GNOME-Bugzilla-Component=general
X-GNOME-Bugzilla-OtherBinaries=gnome-calculator

(info from the bug-buddy maintainer:)

> What is it?

Metainformation about the application used to report bugs on out BTS
      
> Which parts are mandatory? Optional?
        
X-GNOME-Bugzilla-Bugzilla=GNOME <-- Mandatory
X-GNOME-Bugzilla-Product=XXX <--Mandatory
X-GNOME-Bugzilla-Component=YYY <-- Mandatory
X-GNOME-Bugzilla-OtherBinaries=ZZZ <-- Optional, only if you
application has several binaries
X-GNOME-Bugzilla-Version=X.Y.Z <-- Optional, and should need expansion
from configure script, so if you want this you need a
application.desktop.in.in to expand here @VERSION@
(application.desktop.in is used by intltool for translations).

> How long has it been there?

circa 2002

> Is it going to change again?

No and yes. If you refer at the field names, they haven't changed
since 2002 (X-GNOME-Bugzilla-Version was added on 2003). If you mean
the values, bugzilla product/component could be changed if the
maintainer ask the bugmaster to do it and should update the info in
the desktop file after the change. As I mentioned on a previous email,
afer this product/component renaming would break any old instalation
of the application for submiting bugs, but we are working on a server
side fallback to solve it.

As this bug applies to Aisleriot, I think the problem we are seeing is related to a new level of strictness that wasn't there before. I am building the latest set with jhbuild and will test my theory by adding OtherBinaries=sol - hopefully that will fix it.

Jason, what's the progress on this bug so far?

jhbuild has been broken. I am trying to rebuild it now. As far as I can tell everything but Aisleriot (sol) still works with bug-buddy because the bugzilla name is the same as the binary name.

Please also add the X-GNOME-Bugzilla-Version in all .desktop files. Such information will not be asked anymore and having the version will be very useful (I'm sure you will agree). It can be in the form of 2.15.x or 2.15.1 (server will silently assume both are 2.15.x). Product+component information must be incorrect. If not, bug-buddy will not work (it will only allow the user to save the report somewhere for manual reporting).

Unfortunately, 8 hours of attempting to get GNOME to build resulted in nothing. 

There are bugs in dbus-glib, libglade, hal, libvolume-id, jhbuild and most recently gnome-icon-theme which prevent a jhbuild from working. I got tired of fighting with it, filing bugs, and tracking down developers.

I will wait for a Debian Unstable upload of bug-buddy 2.15.0 and then build gnome-games against that and test the new .desktop modifications.

If someone has a successful build before then let me know and I'll pull CVS immediately so that I can try it too.

Unfortunately, I haven't been able to build GNOME either yet.

If you could post a patch here, or the .desktop file if that's the only thing that changed, I would be glad to test it out.

Jason, I think that the build problems for GNOME have been resolved, so you could give it a try again now.   :)

I was never able to get a working built our of jhbuild; as soon as 2.16.x hits Debian, I'll fix this bug.

(In reply to comment #7)
> Unfortunately, 8 hours of attempting to get GNOME to build resulted in nothing. 
> 
> There are bugs in dbus-glib, libglade, hal, libvolume-id, jhbuild and most
> recently gnome-icon-theme which prevent a jhbuild from working. I got tired of
> fighting with it, filing bugs, and tracking down developers.

Wow, I wish I would have been aware of this example earlier.  I had told people on the lists that build problems were cutting into developer time; I hadn't been aware of a case of it preventing a maintainer from working on his module.  That *really* sucks.  I hope the changes we're making with external dependencies and such kill most of these problems.

Jason, about the gnome-target field: gnome-target is meant to be used on bugs severe enough to possibly require delaying GNOME releases.  The target milestone is the field you want for bugs you'd like to remember to fix by a certain release.  You can add target milestones for your product by clicking on the "Edit this product" link in the lower-right hand corner of the browse.cgi ("product overview") page.  See also the "Target Milestone" and "GNOME Target Milestone" sections of http://bugzilla.gnome.org/page.cgi?id=bug-status.html.  :-)

Thanks for the attention. Yes, it was disheartening. I haven't tried jhbuild since then. I have garnome on my to-do list.

In the mean time, bug-buddy >= 2.15 is about to hit Debian Unstable so it should be only 1 week more, at the most, before this bug is fixed.

The following games do not work with Bug Buddy 2.16:

Aisleriot (sol) -- FreeCell by extension
Blackjack

I just fixed gnome-sudoku and glchess and the rest looks ok. Time to close this?

Comment #14 is still applicable. You can try it yourself by sending sig 7 to a running game and watching bug-buddy claim that it doesn't know anything about the crashed application.

We really should get X-GNOME-Bugzilla-Version set too. Should that be in a separate bug or do we just unblock #348827 when aisleriot and blackjack are done?

Created attachment 89235 [details] [review]
add gnome-games version to the desktop files for bugzilla integration

Christian, why do you modify configure.in and po/POTFILES.in in the patch of comment #18?

Because the .desktop.in.in files are the master files, and the .desktop.in files generated from the .in.in files at configure time.

Note that this is a git diff; applying it with the standard patch command will _not_ do the right thing (it doesn't recognise the moved files).

I see, (don't know why I didn't realize that...)  Then the patch looks good.

Committed.