Bug 554678

Here is the diff between the two gir files:

--- Gtk-2.0.gir.i686‣‧‧‧2010-02-14 19:14:03.447942686 -0500
+++ Gtk-2.0.gir.x86_64‣‧2010-02-14 19:13:06.184942785 -0500
@@ -10852,7 +10852,6 @@
                glib:type-name="GtkCellEditable"
                glib:get-type="gtk_cell_editable_get_type"
                glib:type-struct="CellEditableIface">
-      <prerequisite name="GObject.InitiallyUnowned"/>
       <prerequisite name="Object"/>
       <prerequisite name="Widget"/>
       <virtual-method name="start_editing" invoker="start_editing">
@@ -21742,7 +21741,6 @@
                c:type="GtkFileChooser"
                glib:type-name="GtkFileChooser"
                glib:get-type="gtk_file_chooser_get_type">
-      <prerequisite name="GObject.InitiallyUnowned"/>
       <prerequisite name="Object"/>
       <prerequisite name="Widget"/>
       <method name="set_action"
@@ -65157,7 +65155,6 @@
                glib:type-name="GtkToolShell"
                glib:get-type="gtk_tool_shell_get_type"
                glib:type-struct="ToolShellIface">
-      <prerequisite name="GObject.InitiallyUnowned"/>
       <prerequisite name="Object"/>
       <prerequisite name="Widget"/>
       <virtual-method name="get_icon_size" invoker="get_icon_size">

Colin, any idea ?

The x86_64 version is clearly broken; the question is why? Investigating.

So testing building GTK+ from git against gobject-introspection git, I definitely get GObject.InitiallyUnowned in all 3 of those cases.

However the latest koji build of 2.19 shows the difference still.

Note the difference on this test program between GTK+ 2.18 and 2.19:

[walters@megatron tmp]$ rpm -q gtk2
gtk2-2.18.6-3.fc12.x86_64
[walters@megatron tmp]$ ./prereq 
1 prerequisites: 
  GtkWidget
# jhbuild as of commit 046b7601274e9b4ad065af754294b94830eebe6d
[walters@megatron tmp]$ jhbuild run ./prereq 
Gtk-Message: Failed to load module "pk-gtk-module": libpk-gtk-module.so: cannot open shared object file: No such file or directory
Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: cannot open shared object file: No such file or directory
3 prerequisites: 
  GInitiallyUnowned
  GtkObject
  GtkWidget

Created attachment 394634 [details]
test program

Tossing this back down to glib.

Fixed in upstream master 63a6666ab7a54c9584b6579e323301f3528e86b3. As the commit message says, code could randomly return superclasses, so I guess checking or rebuilding all gir files is a good idea.

Also, I'm not used to that code at all, so I might have broken something accidentally. As you seem to be one of the rare users of g_type_interface_prerequisites(), please keep an eye open for possible new breakages.

Thanks Benjamin!  Let's close this, it should fix itself once things get gradually rebuilt.

This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping