pango-1.28.4 uses the G_CONST_RETURN pre-processor macro in its C source and its public headers. The G_CONST_RETURN macro was formally deprecated in glib-2.30. This is more a problem with packages that directly or indirectly depend on the pango headers to build, and that define the G_DISABLE_DEPRECATED C pre-processor macro, but there seem to be a few of these that fail to compile because of it: net-dns/avahi-0.6.30-r1 (bug 384743) gnome-base/libglade-2.6.4 (bug 384775) app-text/poppler-0.16.7 (no bug added yet) Rather than fix all these individually, it might be better to fix it once in pango. See http://git.gnome.org/browse/pango/commit/?id=4c7807daee7189f481d7c18b56b06d7b7dba7884 for the git commit and http://git.gnome.org/browse/pango/patch/?id=4c7807daee7189f481d7c18b56b06d7b7dba7884 for the patch. The patch applies to the pango-1.28.4 source (with a few hunk offsets) and changes all the G_CONST_RETURN to const in the C source. Reproducible: Always
(In reply to comment #0) [...] > Rather than fix all these individually, it might be better to fix it once in > pango. [...] Anyway, keep opening bug reports (and make them depend on this one to let me go for fixing them when I have time) for failing packages as they should be dropping DEPRECATED flags for a long time since they shouldn't be used in tarball releases Thanks
(In reply to comment #1) > (In reply to comment #0) > [...] > > Rather than fix all these individually, it might be better to fix it once in > > pango. > [...] > It didn't suffice here, since /usr/include/atk-1.0/atk/atkobject.h still contains G_CONST_RETURN This still makes the ebuilds for libglade and avahi fail. So, we need a patch for atk, as well. Helmut.
No, we need avahi/libglade/whatever NOT pass -DG_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED and so on
(In reply to comment #3) > No, we need avahi/libglade/whatever NOT pass -DG_DISABLE_DEPRECATED > -DGTK_DISABLE_DEPRECATED and so on It's significantly faster and easier for us to fix public headers in 2 packages (pango and atk) than to chase down and patch >9000 random packages that use pango and/or atk and enable G_DISABLE_DEPRECATED somewhere in their build system and get all their maintainers to apply patches.
net-misc/network-manager-vpnc-0.8.2 has this issue as well. bug #384987
And media-libs/clutter-gst-1.3.14 (see bug #385171).
*** Bug 385519 has been marked as a duplicate of this bug. ***
*** Bug 386011 has been marked as a duplicate of this bug. ***
*** Bug 384919 has been marked as a duplicate of this bug. ***
bugs 384987, 385503, 385597 are now only affecting to hardmasked versions, would be nice if gnome3 developers could fix them, but they shouldn't block a glib-2.30 stabilization as they are hardmasked anyway bug 388509 should neither block it as G_CONST problem is fixed, it's still not building due unrelated problems As I have finally rebuilt most of the tree, I think glib-2.30 is now safe to go to stable (at least talking about this kind of problems)
(In reply to comment #4) > (In reply to comment #3) > > No, we need avahi/libglade/whatever NOT pass -DG_DISABLE_DEPRECATED > > -DGTK_DISABLE_DEPRECATED and so on > > It's significantly faster and easier for us to fix public headers in 2 packages > (pango and atk) than to chase down and patch >9000 random packages that use > pango and/or atk and enable G_DISABLE_DEPRECATED somewhere in their build > system and get all their maintainers to apply patches. No, *_DISABLE_DEPRECATED must NOT be passed in any stable release versions and we need to fix them sooner or later anyway. This gives us a good trigger to show when there is this problem of having em passed. We can't predict the future. If we don't filter out this -DG_DISABLE_DEPRECATED stuff now, it's going to bite us again the next time something gets deprecated in the next version, and I ensure you, there will be something, and then we get to deal with this all over again. We should also make sure upstream configure.ac's are fixed to not pass those things in even minor version number cases (stable releases) - there should be standard m4 macros for handling that in gnome-common I presume.
Just as I post this, it occurs me that glib rethoughts it deprecation handling and now I believe wants projects to just catch these by -Werror in development releases (deprecations usages emit compiler warnings), so actually many of them might be converting to that method now, and hopefully not ever pass -D*_DISABLE_DEPRECATED, just -Werror in development/git builds. On that light, after some research I may agree with changing public headers instead.
All should be fixed now as bug 388509 remaining problems are not related with glib-2.30
gnome-extra/gnome-do-0.8.5 also fails compilation because of G_CONST_RETURN. Replacing it for const in pango headers solves the errors.
(In reply to comment #14) > gnome-extra/gnome-do-0.8.5 also fails compilation because of G_CONST_RETURN. > Replacing it for const in pango headers solves the errors. I think you'll need to create a new bug report....
(In reply to comment #14) > gnome-extra/gnome-do-0.8.5 also fails compilation because of G_CONST_RETURN. > Replacing it for const in pango headers solves the errors. + 06 Jan 2012; Pacho Ramos <pacho@gentoo.org> gnome-do-0.8.5.ebuild: + Drop DEPRECATED flags (bug #384779 comment #14 by Jeff) and -Werror. + For next time open a separate bug report and make it block this one ;)
