GNOME Bugzilla – Bug 560285
GNOME Goal: Remove deprecated GLib symbols
Last modified: 2009-02-06 09:09:42 UTC
Attaching a patch to remove deprecated GLib Symbols
Created attachment 122391 [details] [review] patch file
Attached is a patch Use: ekiga-SOURCE-DIR$ patch -p0 < ekiga-3.0.1-cleanup-deprecated-glib-symbols.patch
Thank you, but : (1) we do know how to apply a patch ; (2) the function you want to remove isn't deprecated yet as far as I know ; (3) the function you want to use is only in glib since 2.16.0 and ekiga still depends on only 2.8.0.
(In reply to comment #3) > Thank you, but : > (1) we do know how to apply a patch ; > (2) the function you want to remove isn't deprecated yet as far as I know ; > (3) the function you want to use is only in glib since 2.16.0 and ekiga still > depends on only 2.8.0. > 1) Just trying to be thorough. :) 2) This is a list of the current glib deprecated symbols which the symbol I replaced is one: http://library.gnome.org/devel/glib/stable/ix02.html 3) The ekiga package was placed under the TODO area for finding and replacing deprecated glib symbols so I did it. The list is here: http://live.gnome.org/GnomeGoals/RemoveDeprecatedSymbols/Glib
*** Bug 560426 has been marked as a duplicate of this bug. ***
Snark: bug 560426 isn't strictly a duplicate. This one is just a subset of bug 560426. You overlook the use of g_main_quit: ekiga/src/components/dbus-helper.cpp:154: g_main_quit (loop); It should be replaced by g_main_loop_quit. As for g_win32_get_package_installation_directory, it has been deprecated in glib 2.18. It should therefore be replaced by g_win32_get_package_installation_directory_of_module. As Ekiga still depends on GLib 2.8, code should be #ifdef'ed using GLIB_CHECK_VERSION to check which GLib version we're using, and use the right function call for both cases.
ping ! Louis, will you do it, or do you want me to do the actual patch ?
I saw the status was set to 'rejected' so I didn't want to continue further with the patch. I you have time I'd appreciate it if you'd do the patching. Thanks! -Louis
Sigh... the patch wasn't rejected because it was bad or I don't like you, but because that means pushing the build dependencies higher than we wanted : if we push too high, ekiga can't be easily packaged for some distributions. Having a perfect code which nobody can build&use would be pointless! Looking at http://www.gtk.org/download-windows.html, I see that glib 2.18 is available for win32 ; looking in /usr/share/doc/libglib2.0-0/changelog.Debian.gz, I see that glib 2.16.6 is available for debian/unstable. What do users of ubuntu, mandriva and suse have?
I haven't taken any offense. I was just stating the patch status was set to 'rejected' which is just a fact. You're a developer so I'm sure you know what's best for the code.
Well, maybe Snark should have set it to "needs-work". Using the instructions I've written in comment 6, the problem Snark evokes about too recent dependencies can be easily workaround. Snark, BTW, it's GLib 2.18 that is used on latest stable Mandriva Linux. I imagine it's the same for Ubuntu and openSuse, as they are usualy released a few days after Mandriva Linux.
Created attachment 128068 [details] [review] use #if #else to use the correct code based on glib version Patch based on original patch and comments. g_main_quit issue has been fixed in the meantime.
Thanks, it's in!