Re: [Ekiga-devel-list] deprecated function does not work in gtk 2.14
Julien Puydt wrote: Julien Puydt a écrit : Eugen Dedu a écrit : The reason is that gtk_file_chooser_button_new_with_backend is deprecated, cf. http://library.gnome.org/devel/gtk/stable/GtkFileChooserButton.html#gtk-file-chooser-button-new-with-backend Unfortunately, the API does not inform about the function to be used in this case. Do you know how to replace this function? I had a bug about such documentation problems : it was closed -- the gtk+ developpers prefer separate bug reports for each of those problems. I reported it : http://bugzilla.gnome.org/show_bug.cgi?id=563991 It's fixed, now the doc reads : Use gtk_file_chooser_button_new() instead. Hi Snark, 1. Where was it fixed? The page http://library.gnome.org/devel/gtk/stable/GtkFileChooserButton.html#gtk-file-chooser-button-new-with-backend is still the same. 2. Have you fixed the code? I would like to create the tarball for gnome 2.25.3 tomorrow. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] A final problem
Peter Robinson wrote: Sounds reasonable to me. There's a 2.14 gtk release on the gtk site but no idea if that's the one ekiga uses. http://www.gtk.org/download-windows.html BTW is 3.0.2 general due at some stage. I suppose gnome will release a third update in about 2 weeks. We plan to release 3.0.2 (or directly 3.0.3) at that date (in my opinion). Yes, we should stick to the GNOME schedule and : 1) release 3.0.2 together with the next stable GNOME release 2) release 3.1.0 unstable with the next unstable GNOME release (15th of December?) I count on you to remind me and Robert to do the appropriate tags in SVN. Well the tarballs for the next 2.25 release are due in 4 days. The 2.24.2 release was late Nov so we missed that one, but the 2.24.3 is not due until mid Jan so I'm not sure if there's enough 3.0.x patches in the tree to do a 3.0.2 at the same time as the 3.1.0 to get fixes out there. http://live.gnome.org/TwoPointTwentyfive Hi, I am sorry, I do not have the time for that right now. Please do it yourself, I try to take care for the other releases. Thanks! -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Trunk ptlib compilation errors
Hi,
A recent check-in in ptlib
(http://opalvoip.svn.sourceforge.net/viewvc/opalvoip?limit_changes=0view=revrevision=21788)
removed #include ptlib.h from several header files. This leads to
compilation errors in ekiga, such as:
g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../lib/gmconf
-I../../../../lib/engine/framework
-I../../../../lib/engine/audiooutput/skel
-I../../../../lib/engine/audioinput/skel
-I../../../../lib/engine/audioinput/null
-I../../../../lib/engine/hal/skel -I/usr/include/sigc++-2.0
-I/usr/lib/sigc++-2.0/include -pthread -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1
-fno-exceptions -I/usr/include/SDL -Wall -g -O2 -Wall -Wextra
-Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2
-Wfloat-equal -Wshadow -MT audioinput-manager-null.lo -MD -MP -MF
.deps/audioinput-manager-null.Tpo -c
../../../../lib/engine/audioinput/null/audioinput-manager-null.cpp
-fPIC -DPIC -o .libs/audioinput-manager-null.o
In file included from
../../../../lib/engine/audioinput/null/audioinput-manager-null.h:45,
from
../../../../lib/engine/audioinput/null/audioinput-manager-null.cpp:35:
/usr/include/ptclib/delaychan.h:49: error: expected class-name before
‘{’ token
/usr/include/ptclib/delaychan.h:50: error: ‘PObject’ has not been declared
I do not know whether if it was done intentionally or not. I suppose it
was by accident, otherwise ekiga should include ptlib.h explicitly in
some cases.
You can see the files which removed ptlib.h inclusion with
svn diff -r 21787:21788 | less
and search for
^-[^-].*ptlib.h
Cheers,
--
Eugen
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] A final problem
Peter Robinson wrote: gtk 2.14 afaict http://library.gnome.org/devel/gtk/stable/gtk-Filesystem-utilities.html#gtk-show-uri OK; let's wait a bit that it is more widespread. Debian still has 2.12. Any chance of a if gtk 2.14 disable libgnome and use gtk_show_uri else include gnome.h and use gnome_help_display ? Would be nice to have the option of disabling libgnome and friends entirely for ekiga 3.2. It seems a bit complicated. But perhaps right before 3.2 we can switch to the new GTK. We only need it built for WIN32. If it is built for WIN32, we can switch. Sounds reasonable to me. There's a 2.14 gtk release on the gtk site but no idea if that's the one ekiga uses. http://www.gtk.org/download-windows.html BTW is 3.0.2 general due at some stage. I suppose gnome will release a third update in about 2 weeks. We plan to release 3.0.2 (or directly 3.0.3) at that date (in my opinion). -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] notify lib includes non top-level header
Hi, It seems ekiga is ahead of time for gtk_single_includes. I receive the following error: make[3]: Entering directory `/home/dedu/softs/ekiga/ekiga/src' g++ -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib/gmconf -I../lib/toolbox -I../lib/gui -I../lib/engine/ -I../lib/engine/framework -I../lib/engine/gui/gtk-frontend -I../lib/engine/account/skel -I../lib/engine/addressbook/skel -I../lib/engine/chat/skel -I../lib/engine/presence/skel -I../lib/engine/protocol/skel -I../lib/engine/protocol/sip -I../lib/engine/videooutput/skel -I../lib/engine/videoinput/skel -I../lib/engine/audioinput/skel -I../lib/engine/audiooutput/skel -I../lib/engine/hal/skel -I../lib/engine/framework -I../lib/engine/gui/gtk-core -I../lib/engine/components/opal -I../src -I../src/dbus-helper/ -I../src/gui/ -I.. -DSCHEMA_AGE=62 -I../lib/engine/videooutput/common -I../lib/engine/videooutput/x-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DG_DISABLE_SINGLE_INCLUDES -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions -I/usr/include/opal -I/usr/include/SDL -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions -I/usr/include/SDL -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/libxml2 -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -Wall -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o `test -f 'gui/main.cpp' || echo './'`gui/main.cpp In file included from /usr/include/libnotify/notification.h:28, from /usr/include/libnotify/notify.h:27, from gui/main.cpp:85: /usr/include/gtk-2.0/gtk/gtkversion.h:28:2: error: #error Only gtk/gtk.h can be included directly. The error is that /usr/include/libnotify/notification.h:28 includes a non top-level header :o( I sent a bug report (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508329), but I don't know when it will be fixed. Also, it is fixed in the next version of libnotify (0.4.5), not yet packages in debian. Until then, the best solution I see is to remove -DGTK_DISABLE_SINGLE_INCLUDES for src/gui/main.cpp Cheers, -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] deprecated function does not work in gtk 2.14
Hi, I have 2.14 installed on my machine. I receive the following error: g++ -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib/gmconf -I../lib/toolbox -I../lib/gui -I../lib/engine/ -I../lib/engine/framework -I../lib/engine/gui/gtk-frontend -I../lib/engine/account/skel -I../lib/engine/addressbook/skel -I../lib/engine/chat/skel -I../lib/engine/presence/skel -I../lib/engine/protocol/skel -I../lib/engine/protocol/sip -I../lib/engine/videooutput/skel -I../lib/engine/videoinput/skel -I../lib/engine/audioinput/skel -I../lib/engine/audiooutput/skel -I../lib/engine/hal/skel -I../lib/engine/framework -I../lib/engine/gui/gtk-core -I../lib/engine/components/opal -I../src -I../src/dbus-helper/ -I../src/gui/ -I.. -DSCHEMA_AGE=62 -I../lib/engine/videooutput/common -I../lib/engine/videooutput/x-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DG_DISABLE_SINGLE_INCLUDES -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions -I/usr/include/opal -I/usr/include/SDL -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions -I/usr/include/SDL -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/libxml2 -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -Wall -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT preferences.o -MD -MP -MF .deps/preferences.Tpo -c -o preferences.o `test -f 'gui/preferences.cpp' || echo './'`gui/preferences.cpp gui/preferences.cpp: In function ‘void gm_pw_init_sound_events_page(GtkWidget*, GtkWidget*)’: gui/preferences.cpp:535: error: ‘gtk_file_chooser_button_new_with_backend’ was not declared in this scope The reason is that gtk_file_chooser_button_new_with_backend is deprecated, cf. http://library.gnome.org/devel/gtk/stable/GtkFileChooserButton.html#gtk-file-chooser-button-new-with-backend Unfortunately, the API does not inform about the function to be used in this case. Do you know how to replace this function? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] A final problem
Damien Sandras wrote: Le lundi 08 décembre 2008 à 22:25 +0100, Eugen Dedu a écrit : Finally, after ./configure --enable-maintainer-mode --build x86_64-linux-gnu --prefix=/usr --sysconfdir=/etc --disable-schemas-install --disable-scrollkeeper I have: Final configuration === Installing into prefix : /usr GNOME support : disabled Why is the gnome support disabled?? Also, if you know, please tell me if the following debian build-dependencies are still needed: libgnome2-dev, libgnomeui-dev, I see this in configure.ac, so yes, they are still needed, otherwise GNOME support is disabled : PKG_CHECK_MODULES([GNOME], [libgnome-2.0 = 2.14.0 libgnomeui-2.0 = 2.14.0], [found_gnome=yes]) Thanks for the information about the two packages. Now, why gnome is disabled?? I have these two -dev packages installed! It's the same configuration as for stable packages. The output is at: http://eugen.dedu.free.fr/ekiga-snapshot_0-20081208-1_amd64.build -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] A final problem
Damien Sandras wrote: Le mardi 09 décembre 2008 à 22:32 +0100, Eugen Dedu a écrit : Damien Sandras wrote: Le lundi 08 décembre 2008 à 22:25 +0100, Eugen Dedu a écrit : Finally, after ./configure --enable-maintainer-mode --build x86_64-linux-gnu --prefix=/usr --sysconfdir=/etc --disable-schemas-install --disable-scrollkeeper I have: Final configuration === Installing into prefix : /usr GNOME support : disabled Why is the gnome support disabled?? Also, if you know, please tell me if the following debian build-dependencies are still needed: libgnome2-dev, libgnomeui-dev, I see this in configure.ac, so yes, they are still needed, otherwise GNOME support is disabled : PKG_CHECK_MODULES([GNOME], [libgnome-2.0 = 2.14.0 libgnomeui-2.0 = 2.14.0], [found_gnome=yes]) Thanks for the information about the two packages. Now, why gnome is disabled?? I have these two -dev packages installed! It's the same configuration as for stable packages. The output is at: http://eugen.dedu.free.fr/ekiga-snapshot_0-20081208-1_amd64.build #mkdir build-gtkonly #cd build-gtkonly ; ./autogen.sh --build x86_64-linux-gnu --prefix=/usr \ # --sysconfdir=/etc --disable-schemas-install --disable-scrollkeeper \ # --disable-gnome I think the answer is there : --disable-gnome This is commented out! The next line is the configuration line. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] A final problem
Peter Robinson wrote: On Tue, Dec 9, 2008 at 9:39 PM, Damien Sandras [EMAIL PROTECTED] wrote: Le lundi 08 décembre 2008 à 22:25 +0100, Eugen Dedu a écrit : Finally, after ./configure --enable-maintainer-mode --build x86_64-linux-gnu --prefix=/usr --sysconfdir=/etc --disable-schemas-install --disable-scrollkeeper I have: Final configuration === Installing into prefix : /usr GNOME support : disabled Why is the gnome support disabled?? Also, if you know, please tell me if the following debian build-dependencies are still needed: libgnome2-dev, libgnomeui-dev, I see this in configure.ac, so yes, they are still needed, otherwise GNOME support is disabled : PKG_CHECK_MODULES([GNOME], [libgnome-2.0 = 2.14.0 libgnomeui-2.0 = 2.14.0], [found_gnome=yes]) I noticed gnome.h is used in one spot still in src/gui/callbacks.cpp but once that is gone I would think the whole check for 'gnome' can be removed. Other than that what is now the difference between the gnome and gtk version? If I understood correctly, the difference is also the gconf settings: in the gconf database or in files; this was also the difference between gtk-only package and the gnome one. Could someone confirm if it's true? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] A final problem
Damien Sandras wrote: Le mardi 09 décembre 2008 à 22:19 +0100, Peter Robinson a écrit : ./configure --enable-maintainer-mode --build x86_64-linux-gnu --prefix=/usr --sysconfdir=/etc --disable-schemas-install --disable-scrollkeeper I have: Final configuration === Installing into prefix : /usr GNOME support : disabled Why is the gnome support disabled?? Also, if you know, please tell me if the following debian build-dependencies are still needed: libgnome2-dev, libgnomeui-dev, I see this in configure.ac, so yes, they are still needed, otherwise GNOME support is disabled : PKG_CHECK_MODULES([GNOME], [libgnome-2.0 = 2.14.0 libgnomeui-2.0 = 2.14.0], [found_gnome=yes]) I noticed gnome.h is used in one spot still in src/gui/callbacks.cpp but once that is gone I would think the whole check for 'gnome' can be removed. Other than that what is now the difference between the gnome and gtk version? I think we removed everything. The only remaining item is gnome_help_display to display the help. Which means we then can't remove the libgnome includes. It looks like most gnome apps (such as gnome-games) are replacing the call with gtk_show_uri , is there a reason we can't or don't want to use that? Ah yes, gnome_show_uri is another use of the GNOME libs. I do not have gtk_show_uri defined on my system. Perhaps it is too new ? gtk 2.14 afaict http://library.gnome.org/devel/gtk/stable/gtk-Filesystem-utilities.html#gtk-show-uri OK; let's wait a bit that it is more widespread. Debian still has 2.12. For information, 2.14 is in experimental. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Compilation error
Hi, From trunk: ekiga has compilation error: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/gmconf -I../../lib -I../../lib/engine/framework -I../../lib/engine/protocol/skel -I../.. -I../.. -I../../lib/pixops -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DG_DISABLE_SINGLE_INCLUDES -Wall -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT gmpreferences.lo -MD -MP -MF .deps/gmpreferences.Tpo -c ../../lib/gui/gmpreferences.c -fPIC -DPIC -o .libs/gmpreferences.o In file included from ../../lib/gui/gmpreferences.c:45: /usr/include/gtk-2.0/gdk/gdkcolor.h:28:2: error: #error Only gdk/gdk.h can be included directly. In /usr/include/gtk-2.0/gdk/gdkcolor.h:28, there is: #if defined(GTK_DISABLE_SINGLE_INCLUDES) !defined (__GDK_H_INSIDE__) !defined (GDK_COMPILATION) #error Only gdk/gdk.h can be included directly. #endif As you compile with -DGTK_DISABLE_SINGLE_INCLUDES, this code generates an error. I suppose you should replace in lib/gui/gmpreferences.c, line 45 (which works in my case): #include gdk/gdkcolor.h with #include gdk/gdk.h (This error is seen here too: http://linux.thai.net/~thep/gnome226-tinderbox/ekiga.html) Cheers, -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Another strange compilation error from trunk
make[3]: Entering directory `/home/dedu/softs/ekiga/ekiga/src' g++ -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib/gmconf -I../lib/toolbox -I../lib/gui -I../lib/engine/ -I../lib/engine/framework -I../lib/engine/gui/gtk-frontend -I../lib/engine/account/skel -I../lib/engine/addressbook/skel -I../lib/engine/chat/skel -I../lib/engine/presence/skel -I../lib/engine/protocol/skel -I../lib/engine/protocol/sip -I../lib/engine/videooutput/skel -I../lib/engine/videoinput/skel -I../lib/engine/audioinput/skel -I../lib/engine/audiooutput/skel -I../lib/engine/hal/skel -I../lib/engine/framework -I../lib/engine/gui/gtk-core -I../lib/engine/components/opal -I../src -I../src/dbus-helper/ -I../src/gui/ -I.. -DSCHEMA_AGE=62 -I../lib/engine/videooutput/common -I../lib/engine/videooutput/x-D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DG_DISABLE_SINGLE_INCLUDES -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions -I/usr/include/opal -I/usr/include/SDL -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions -I/usr/include/SDL -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/libxml2 -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -Wall -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT callbacks.o -MD -MP -MF .deps/callbacks.Tpo -c -o callbacks.o `test -f 'gui/callbacks.cpp' || echo './'`gui/callbacks.cpp gui/callbacks.cpp: In function ‘void about_callback(GtkWidget*, void*)’: gui/callbacks.cpp:129: error: ‘N_’ was not declared in this scope gui/callbacks.cpp:153: error: ‘gettext’ was not declared in this scope gui/callbacks.cpp:188: error: ‘_’ was not declared in this scope gui/callbacks.cpp: In function ‘void help_cb(GtkWidget*, void*)’: gui/callbacks.cpp:275: error: ‘_’ was not declared in this scope make[3]: *** [callbacks.o] Error 1 gettext not found?? What might be the reason? I added #include libintl.h but the compilation still stops. And I have gettext installed: snoopy:~/softs/ekiga/ekiga$ dpkg -l \*gettext\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gettext0.17-6 GNU Internationalization utilities ii gettext-base 0.17-6 GNU Internationalization utilities for the base syst un gettext-docnone (no description available) ii gettext-el 0.17-6 Emacs po-mode for editing gettext .po files un libgettextpo-dev none (no description available) un libgettextpo0 none (no description available) ii liblocale-gettext- 1.05-4 Using libc functions for internationalization in Per snoopy:~/softs/ekiga/ekiga$ -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] A final problem
Finally, after ./configure --enable-maintainer-mode --build x86_64-linux-gnu --prefix=/usr --sysconfdir=/etc --disable-schemas-install --disable-scrollkeeper I have: Final configuration === Installing into prefix : /usr GNOME support : disabled Why is the gnome support disabled?? Also, if you know, please tell me if the following debian build-dependencies are still needed: libgnome2-dev, libgnomeui-dev, -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] GNOME Schedule : help needed
Damien Sandras wrote: Le samedi 06 décembre 2008 à 11:34 +0100, Damien Sandras a écrit : Dear all, As many of you might have noticed, I have less and less time to devote to Ekiga. It does not mean that I am leaving the project or that I won't contribute anymore. However, it does mean that I need help for some tasks that are time consuming because I could spend that time to code on new features. GNOME has a schedule to respect, both to release new stable releases (3.0.x) and unstable releases (3.1.x that will lead to stable 3.2). Each new Ekiga release requires a release of OPAL and PTLIB. What I would need is : - somebody who checks the GNOME release schedules and : * asks the PTLIB/OPAL maintainers if they can do new releases * generate a new tarball and a new release for Ekiga * upload the tarballs on ekiga.org and on master.gnome.org * write the release announcement based on the NEWS file Who can help doing that ? If possible, that would be someone following the project daily. (I'm thinking to Snark, TheBonsai, yannick, matthias, Peter, Fabrice, ...) Nobody ? I will try myself. Ok? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Debian packages
Hi, This email summarises information about debian packages on ekiga Web site, http://snapshots.ekiga.net. This site provides three kinds of packages: 1. one package for non-free codecs, to be installed together with official debian packages currently from experimental 2. snapshot packages from the stable branch (which should be more stable than official debian's ones) 3. snaphots packages from the trunk (unstable), not yet available More information can be found at http://snapshots.ekiga.net. Cheers, -- Eugen Dedu ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Error compiling
With stable branches, I have 2 compilation errors in ekiga: g++ -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib/gmconf -I../lib/toolbox -I../lib/gui -I../lib/engine/ -I../lib/engine/gui/gtk-frontend -I../lib/engine/account/skel -I../lib/engine/addressbook/skel -I../lib/engine/chat/skel -I../lib/engine/presence/skel -I../lib/engine/protocol/skel -I../lib/engine/protocol/sip -I../lib/engine/videooutput/skel -I../lib/engine/videoinput/skel -I../lib/engine/audioinput/skel -I../lib/engine/audiooutput/skel -I../lib/engine/hal/skel -I../lib/engine/framework -I../lib/engine/gui/gtk-core -I../src -I../src/clients/ -I../src/components/ -I../src/devices/ -I../src/endpoints/ -I../src/gui/ -I.. -DSCHEMA_AGE=62 -I../lib/engine/videooutput/common -I../lib/engine/videooutput/x -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DORBIT2=1 -pthread -D_REENTRANT -I/usr/include/libgnome-2.0 -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0 -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions -I/usr/include/opal -I/usr/include/SDL -DPTRACING=1 -D_REENTRANT -D_GNU_SOURCE=1 -fno-exceptions -I/usr/include/SDL -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/libxml2 -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/pixman-1 -Wall -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT main.o -MD -MP -MF .deps/main.Tpo -c -o main.o `test -f 'gui/main.cpp' || echo './'`gui/main.cpp gui/statusmenu.h: In function ‘GtkWidget* gm_mw_init_status_toolbar(GtkWidget*)’: gui/statusmenu.h:86: error: too few arguments to function ‘GtkWidget* status_menu_new(Ekiga::ServiceCore)’ gui/main.cpp:1708: error: at this point in file gui/main.cpp:1709: error: ‘struct _GmMainWindow’ has no member named ‘priv’ gui/main.cpp:1709: error: ‘struct _GmMainWindow’ has no member named ‘priv’ make[4]: *** [main.o] Error 1 make[4]: Leaving directory `/home/dedu/softs/ekiga/ekiga/src' -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] ekiga entered debian repository
Hello, We have the pleasure to inform you that ekiga 3.0.1 has just been uploaded in debian experimental distribution, cf. http://packages.qa.debian.org/e/ekiga.html. It might take a few days to be available on all architectures. Happy ekiga, -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] NEWS file in ekiga
I propose the following NEWS file, to replace the current one. Distributions can use it directly. -- Eugen -*- mode: outline -*- * Changes in ekiga 3.0.1 (2008-10-20) ** Windows build - Fixed crash when echo cancellation is active - Improved GTK installation by providing our own libraries - Fixed crash when clicking the status bar - Fixed crash when the only available accelerated surface is already taken - Fixed playing of audio files with samplerate != 8000Hz - Fixed possible crash when quickly deleting and creating threads - Fixed flickering in Picture-in-Picture mode ** GUI - Fixed overlapping issue of font/smiley buttons in the chat window - Fixed possible flickering issues on XV - Fixed possible X timing issue - Fixed message box when device is unplugged in out-of-call state - Fixed crash when closing various windows using the window manager - Fixed crash in the configuration assistant when unplugging the active device - Do not display localhost users in the neighbours - Fixed Ekiga not able to resolve DNS names when being used with a Turkish locale - Allow using '' as name in the roster - Fixed 'Search Scope' field alignment in the form ** SIP - Fixed behavior in case of Open NAT - Fixed SIP REGISTER and INVITE behaviors when Ekiga listens to multiple interfaces in the same subnet - Fixed response code when receiving a BYE for a call that is already released - Fixed numerous retries using the same authentication credentials - Fixed interoperability issues with Cisco Call Manager - Fixed default status when receiving a NOTIFY with an empty body to offline instead of unknown - Fixed parsing of URIs quoted with but without - Fixed INVITE loop detection when forked INVITE requets arrive over multiple paths ** H.323 - Fixed inclusion of RFC2833 using H.323 ** Misc - Made the libnotify dependancy optional - Fixed POTFILE.in file * Major changes in ekiga 3.0.0 (2008-09-23) ** Graphical User Interface - New user interface with a buddy list - Accelerated video display (Unix: XVideo, Windows: DirectDraw) - Nice incoming call notifications - Easier configuration assistant - New quality meter in the status bar - Buddy list with extended status information - Displays network neighbours in the buddy list - Better keyboard shortcuts - Automatic account completion in the URL bar - New chat window - New address book supporting Evolution contacts, LDAP contacts and more - New account window allowing easier account creation - New call panel ** Codecs - H.263+ - H.264 - THEORA - MPEG4 - Framerate up to 30 FPS - Resolutions (up to 704x576) (at best it is DVD quality) - Audio and video codecs as plugins - Support for Intel IPP codecs ** SIP Support - SIP/SIMPLE presence support - Line monitoring with software like Asterisk - Custom presence message support - Dynamic detection of network interfaces - Register/unregister accounts on interfaces going up and down - Better NAT traversal - SIP requests originated from a unique port - Support for several network interfaces at the same time (e.g. VPN and normal network) - Full SIP capabilties exchange for codecs (unique in the Open Source world) - SIP INFO DTMF support - Possibility to send SMS using the Ekiga Call Out account - Many compliance fixes ** Hotplug Support - Hotplug support for audio and video devices (even when being in a call) - Hotplug support for network interfaces ** For Developers and Packagers - Brand new Ekiga Engine, fully separated from the GUI and reusable in other projects - Reworked WIN32 build - Better autoconf support for OPAL___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ANNOUNCE - Ekiga 3.0.1 available
Peter Robinson wrote:
Hi,
In debian, libopal explicitly depends on libspeex1 and libspeexdsp1. This
solves the problem.
That's essentially the same in Fedora, the problem wasn't with opal,
it was in ekiga. Its all detailed in the thread.
Hi,
If opal depends on libspeexdsp too, then ekiga compiles fine (without
depending on speex{dsp}).
So your question was just: why does ekiga check via pkg-config that
speexdsp is there? This check is always true if opal depends on speexdsp...
Sorry if I misunderstand the thread.
--
Eugen
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga-Engine and Interfaces for Ekiga
Heiser Michael wrote: How can I use the plugins for H.263 H.264 within ekiga 3.0. I installed the plugins via the snapshot server. I use Debian-Linux. When I installed the plugins for opal I can't select them in ekiga. Theres only theora and h.261. Also, try this first: have you installed libopal3.4.1-plugins-non-free? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga-Engine and Interfaces for Ekiga
Heiser Michael wrote: Also, try this first: have you installed libopal3.4.1-plugins-non-free? I installed libopal3.4.1-plugins-non-free after installing Ekiga stable from the snapshot server. So should I try to reinstall Ekiga after installing libopal3.4.1-plugins-non-free? No. Please answer the previous email. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compilation errors in ekiga given from opal
Damien Sandras wrote: Le dimanche 05 octobre 2008 à 21:15 +0200, Eugen Dedu a écrit : Damien Sandras wrote: Le dimanche 05 octobre 2008 à 20:03 +0200, Eugen Dedu a écrit : Hi, Snapshots are back... Trying to compile ekiga, I receive an error given because of http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/opal/trunk/src/sip/sipep.cxx?r1=21186r2=21211 (look for first occurrence of the word register for the change) Here is a patch fixing this (it seems that the account with the error is returned in aor2 param, so I use this one). There is a second error which appears, this time I do not know how to cope with it: [...] .deps/sip-endpoint.Tpo -c -o sip-endpoint.o `test -f 'endpoints/sip-endpoint.cpp' || echo './'`endpoints/sip-endpoint.cpp endpoints/sip-endpoint.cpp: In member function ‘SIPURL Opal::Sip::EndPoint::GetRegisteredPartyName(const SIPURL)’: endpoints/sip-endpoint.cpp:1045: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ Is it TRUNK ? I don't plan moving to TRUNK until STABLE is stable enough and 3.0.1 released. Yes, it was trunk. So for the snapshots it is better to use 2.4 branch of ptlib, 3.4 branch of opal, and gnome-2.24 branch of ekiga? For now yes. Ok. Also, are the snapshots interesting enough to be built for the moment? Which ones ? Ok, I'll create snapshots for the three branches above. Thanks, -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compilation errors in ekiga given from opal
Damien Sandras wrote: Le dimanche 05 octobre 2008 à 20:03 +0200, Eugen Dedu a écrit : Hi, Snapshots are back... Trying to compile ekiga, I receive an error given because of http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/opal/trunk/src/sip/sipep.cxx?r1=21186r2=21211 (look for first occurrence of the word register for the change) Here is a patch fixing this (it seems that the account with the error is returned in aor2 param, so I use this one). There is a second error which appears, this time I do not know how to cope with it: [...] .deps/sip-endpoint.Tpo -c -o sip-endpoint.o `test -f 'endpoints/sip-endpoint.cpp' || echo './'`endpoints/sip-endpoint.cpp endpoints/sip-endpoint.cpp: In member function ‘SIPURL Opal::Sip::EndPoint::GetRegisteredPartyName(const SIPURL)’: endpoints/sip-endpoint.cpp:1045: error: ‘class SIPHandler’ has no member named ‘GetTargetAddress’ Is it TRUNK ? I don't plan moving to TRUNK until STABLE is stable enough and 3.0.1 released. Yes, it was trunk. So for the snapshots it is better to use 2.4 branch of ptlib, 3.4 branch of opal, and gnome-2.24 branch of ekiga? Also, are the snapshots interesting enough to be built for the moment? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] To all developers
Damien Sandras wrote: Hello, Could you also please tell the svn co lines for ptlib/opal/ekiga for the final version 3.0.0? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Dependencies
Hi, In snapshots (debian at least): - ekiga depends on libopal, libpt and pt plugins - libopal depends on libpt - libpt depends on pt plugins In official debian: - ekiga depends on libopal and libpt - libopal does not depends on any pt - libpt depends on pt plugins What are the correct dependencies in your opinion? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] locked mutex destroyed at shutdown
Damien Sandras wrote: Le mardi 09 septembre 2008 à 08:44 -0400, Jared D. McNeill a écrit : Damien Sandras wrote: Unfortunately, without gdb, it is like looking for a needle in a haystack :( There are so many mutexes... Is there an equivalent of PTHREAD_DIAGASSERT on Linux that you could use to reproduce the error? Could you install an older version of gdb, which has no problems with threads? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] New debian snapshots
thomas schorpp wrote: Eugen Dedu schrieb: Hi, New debian snapshots are available. from where? ;) http://snapshots.ekiga.net In sources.list: deb http://snapshots.ekiga.net/snapshots/debian/ ./ -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] How to add a new SIP account?
Mike Massonnet wrote: Le Sat, 30 Aug 2008 17:18:34 +0200, Eugen Dedu [EMAIL PROTECTED] a écrit : [EMAIL PROTECTED] wrote: Hello! I am using Ekiga 3.0. I can make long distance calls with my voipdiscount account. But... I'd like to add my Gizmo account too. How I can do that? I can't find this option. Can anyone help me... Please! Edit-Accounts, and Account-Add a sip account in the new window? I have to say, this disturbed me too the first time I ran Ekiga 3.00. The menubar is quite not visible, it looks more like a frame title. Perhaps you could add a mnemonic instead, so we see that Account is clickable. Or something :) The following patch adds A from Account as shortcut, the menu being this more visible: --- ekiga-svn/src/gui/accounts.cpp 2008-08-29 11:28:56.0 +0200 +++ myekiga/src/gui/accounts.cpp2008-08-30 18:29:28.0 +0200 @@ -547,7 +547,7 @@ g_object_unref (aw-accel); aw-menu_item_core = -gtk_menu_item_new_with_mnemonic (_(Account)); +gtk_menu_item_new_with_mnemonic (_(_Account)); gtk_menu_shell_append (GTK_MENU_SHELL (menu_bar), aw-menu_item_core); g_object_ref (aw-menu_item_core); -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] ekiga shows me as away, even if I am typing
Hi, I noticed that ekiga looks at the mouse only (not at the keyboard) to see if I become away. For ex., I type an e-mail for a few minutes without moving the mouse, I change status from online to away. Is it normal? Or maybe do you use a GNOME-specific function to see if a user becomes away? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] ekiga don't show option for h264 in the gui.
Francisco Demeter wrote: Hello, I have installed the snapshot from 12-08-2008 from debian SID and I cannot activate the plug in for h264 video codec compression. I have all so installed the codec h264. But in the gui from ekiga the option dosent came up, so I only have h261 and theora. Have you installed libx264-..., as shown in the description of the 264 plugin package? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Patch sizes
Hi, I would propose you the patch attached, which solves, at least for me, two annoying problems with the size of widgets/window: - the three tabs at the left are not visible entirely (only two are visible and arrows are shown), adding 10 pixels solves this problem for me. I imagine that a general patch takes into account all the languages, but until then... - when changing video size, the window grows in height without reason, so I removed the *2.5. Or simply removing this line, if the user has a long list of contacts in roster and don't want to change its height? -- Eugen --- ../ekiga-svn/src/gui/main.cpp 2008-08-11 22:26:07.0 +0200 +++ src/gui/main.cpp 2008-08-12 11:45:36.0 +0200 @@ -1070,7 +1070,7 @@ gdk_window_invalidate_rect (GDK_WINDOW (GTK_WIDGET (self)-window), rect , TRUE); - gtk_window_resize (GTK_WINDOW (self), width + 20, mw-y ? mw-y : (int) height * 2.5); + gtk_window_resize (GTK_WINDOW (self), width + 50, mw-y ? mw-y : (int) height); } void @@ -3990,7 +3990,7 @@ gm_mw_init_contacts_list (window); gm_mw_init_dialpad (window); gtk_paned_pack1 (GTK_PANED (mw-hpaned), mw-main_notebook, true, true); - gtk_widget_set_size_request (mw-main_notebook, 200, -1); + gtk_widget_set_size_request (mw-main_notebook, 210, -1); gm_mw_init_call (window); gm_mw_init_history (window); ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Patch sizes
Damien Sandras wrote: Le mardi 12 août 2008 à 11:56 +0200, Eugen Dedu a écrit : Hi, I would propose you the patch attached, which solves, at least for me, two annoying problems with the size of widgets/window: - the three tabs at the left are not visible entirely (only two are visible and arrows are shown), adding 10 pixels solves this problem for me. I imagine that a general patch takes into account all the languages, but until then... - when changing video size, the window grows in height without reason, so I removed the *2.5. Or simply removing this line, if the user has a long list of contacts in roster and don't want to change its height? If you remove that line and change the video size, what happens with the video ? - First, in my case (changing video size in prefs and calling [EMAIL PROTECTED]) shows that mw-y is always 0. - Second, width and height are set to the video size, not the window size as it should in gtk_window_resize - Third, without this line, the only difference I see is: - if I resize the window to greater size, afterwards press show video, the window does not resize to pack exactly to the video size, but remains at the same size. In fact, this was catched with the line to be removed, because this line reduces very much the width (but no more than the minimum for video and the three tabs) Conclusion: - the best is to change as little as possible the application: just use the patch as is, i.e. the size will be adjusted to its minimum -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga compilation error
yannick wrote:
Compilation was working yesterday evening (europa) but failed this
morning:
full log:
http://launchpadlibrarian.net/16724491/buildlog_ubuntu-hardy-amd64.ekiga-snapshot_20080812v01hardy3_FAILEDTOBUILD.txt.gz
g++ -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib/gmconf -I../lib/toolbox
-I../lib/gui -I../lib/engine/ -I../lib/engine/gui/gtk-frontend
-I../lib/engine/account/skel -I../lib/engine/addressbook/skel
-I../lib/engine/chat/skel -I../lib/engine/presence/skel
-I../lib/engine/protocol/skel -I../lib/engine/protocol/sip
-I../lib/engine/videooutput/skel -I../lib/engine/videoinput/skel
-I../lib/engine/audioinput/skel -I../lib/engine/audiooutput/skel
-I../lib/engine/hal/skel -I../lib/engine/framework
-I../lib/engine/gui/gtk-core -I../src -I../src/clients/
-I../src/components/ -I../src/devices/ -I../src/endpoints/ -I../src/gui/
-I.. -DSCHEMA_AGE=61 -I../lib/engine/videooutput/common
-I../lib/engine/videooutput/x-DPNG_NO_MMX_CODE
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2
-I/usr/include/libpng12 -I/usr/include/pixman-1 -pthread
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DORBIT2=1
-pthread -DPNG_NO_MMX_CODE -I/usr/include/libgnome-2.0
-I/usr/include/orbit-2.0 -I/usr/include/gconf/2
-I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0
-I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
-I/usr/include/gnome-keyring-1 -I/usr/include/libbonoboui-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0
-I/usr/include/freetype2 -I/usr/include/atk-1.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/libpng12
-I/usr/include/pixman-1 -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include-DPTRACING=1 -D_REENTRANT -fno-exceptions
-I/usr/include/opal -DPTRACING -DNDEBUG -Os -g -fno-exceptions
-felide-constructors -DPTRACING=1 -D_REENTRANT -fno-exceptions
-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/libxml2 -g -O2 -Wall -Wextra -Winit-self
-Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal
-Wshadow -MT opal-account.o -MD -MP -MF .deps/opal-account.Tpo -c -o
opal-account.o `test -f 'endpoints/opal-account.cpp' || echo
'./'`endpoints/opal-account.cpp
endpoints/sip-endpoint.cpp: In member function 'virtual void
Opal::Sip::EndPoint::fetch(std::string)':
endpoints/sip-endpoint.cpp:308: error: 'SubscribeType' is not a member of
'SIPSubscribe'
endpoints/sip-endpoint.cpp:308: error: expected `;' before 'type'
endpoints/sip-endpoint.cpp:309: error: 'type' was not declared in this scope
endpoints/sip-endpoint.cpp: In member function 'virtual void
Opal::Sip::EndPoint::unfetch(std::string)':
endpoints/sip-endpoint.cpp:318: error: 'SubscribeType' is not a member of
'SIPSubscribe'
endpoints/sip-endpoint.cpp:318: error: expected `;' before 'type'
endpoints/sip-endpoint.cpp:319: error: 'type' was not declared in this scope
endpoints/sip-endpoint.cpp: In member function 'virtual void
Opal::Sip::EndPoint::OnRegistered(const PString, bool)':
endpoints/sip-endpoint.cpp:630: error: 'SubscribeType' is not a member of
'SIPSubscribe'
endpoints/sip-endpoint.cpp:630: error: expected `;' before 'type'
endpoints/sip-endpoint.cpp:631: error: 'type' was not declared in this scope
endpoints/sip-endpoint.cpp:640: error: 'SubscribeType' is not a member of
'SIPSubscribe'
endpoints/sip-endpoint.cpp:640: error: expected `;' before 't'
endpoints/sip-endpoint.cpp:641: error: 't' was not declared in this scope
make[4]: *** [sip-endpoint.o] Error 1
It was simpler than I thought, see patch attached (which voids using any
type).
==
For developement info, here is an excerpt of the changes in opal:
- SIPSubscribe::SubscribeType type,
+ const PString eventPackage,
-- SIPSubscribe::SubscribeType changed in const PString
- SIPSubscribe::SubscribeType type;
+ PCaselessString m_eventPackage;
-PSafePtrSIPHandler FindSIPHandlerByUrl(const PString url,
SIP_PDU::Methods meth, SIPSubscribe::SubscribeType type, PSafetyMode m);
+PSafePtrSIPHandler FindSIPHandlerByUrl(const PString url,
SIP_PDU::Methods meth, const PString eventPackage, PSafetyMode m);
-enum SubscribeType {
- Unknown,
- MessageSummary,
- Presence
-};
+static const PString MessageSummary;
+static const PString Presence;
-if (type == SIPSubscribe::Presence)
+if (m_eventPackage == SIPSubscribe::Presence)
-if (SIPURL(url) == handler-GetTargetAddress() meth ==
handler-GetMethod() handler-GetSubscribeType() == type)
+if (SIPURL(url) == handler-GetTargetAddress() meth ==
handler-GetMethod()
[Ekiga-devel-list] Question on package name and ABI change
Hello PTLib and OPAL developers, I am creating ptlib and opal packages to be uploaded in debian experimental from SVN, which can happen very soon. I don't know how to name these packages. I wanted to name them libpt-2.3 and libopal-2.3, but I was told that it cannot be like this, because the ABI of these libraries can change. In fact, it seems the packages should have the same name as the soname, i.e. libpt.so.2.3-beta0 and libopal.so.3.3-beta0, and, in the future, for the following versions, ...-beta1, ...-beta2, ... So what is your proposition? Should I use libpt-2.3-beta0 and libopal-3.3-beta0 as package names, or can I use simply libpt-2.3 and libopal-3.3 provided that the ABI will not change? If the ABI might still change, do you know when the ABI will be frozen? Thanks for your answers, -- Eugen Dedu ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Wrong comment in ptlib dc plugin code
These comments say that avc plugin does not yet exists, but in fact avc plugin does exist. So here is the patch I propose: Cheers, -- Eugen --- video4dc1394.cxx.orig 2008-08-09 10:59:54.0 +0200 +++ video4dc1394.cxx 2008-08-09 11:01:56.0 +0200 @@ -11,20 +11,15 @@ * There are two kind of the specifications of IEEE 1394 digital video * cameras, one is called digital camera and another is AV/C camera. * A digital camera sends uncompressed video data while an AV/C camera - * sends compressed data. Currently PWLib only supports digital - * cameras. We can find a list of supported digital cameras by the Linux + * sends compressed data. This file is for digital cameras. + * We can find a list of supported digital cameras by the Linux * device driver at: * http://www.tele.ucl.ac.be/PEOPLE/DOUXCHAMPS/ieee1394/cameras/ * - * AV/C cameras seem able to be used for video phone. You are welcome to - * write supporting codes for AV/C cameras! - * * * Installation and Use: * - * To enable 1394 camera support, you have to define the TRY_1394DC - * shell environment variable at compilation time of PWLib, OpenH323, and - * ohphone. To select your 1394 camera for video input device instead of + * To select your 1394 camera for video input device instead of * usual Video4Linux devices, specify /dev/raw1394 or /dev/video1394 * as the filename of video input device. For example ohphone * --videoinput /dev/raw1394 should use your 1394 camera as video input. @@ -86,7 +81,7 @@ * * * Internal Structure: - * This module has been tested against the ohphone and GnomeMeeting + * This module has been tested against the ohphone and ekiga/GnomeMeeting * video phone programs. They use 352x288 and 176x144 resolutions in * YUV420P color format. So this module only supports these * resolutions and YUV420P. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] autogen.sh is not explained in INSTALL file
INSTALL file is the classical file, which writes about configure, make, make install. However, ekiga does not have configure, but uses autogen.sh. I propose to add the following sentence in the INSTALL file, or elsewhere, if this file should not be touched: snoopy:~/softs/ekiga/ekiga$ diff INSTALL INSTALL.new 12a13,21 If you are on Windows, please look at the win32 directory instead of this file. ekiga does not come with a configure script, but with the script autogen.sh. So the first step to compile ekiga is to run autogen.sh. You should give it the same parameters as configure. autogen.sh creates the configure file and executes it automatically with the parameters you have given to it. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Unnecessary linked libraries
Hi, During building debian packages of ekiga, ptlib and opal, I receive many warnings about libraries linked uselessly. Can these libraries be removed from the list of linked libraries? I imagine however that they are needed for certain parameteres to configure, so if it is to complicated, let's stay with the actual code. I think (so not sure) that this might have negative influences to entering in debian testing of these packages: imagine that libz does not enter testing, this then prevents ekiga to enter testing, because its executable erroneously depends on it... Here are the warnings: for ekiga: dpkg-shlibdeps: warning: dependency on libz.so.1 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libdbus-1.so.3 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga-helper debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libbonobo-activation.so.4 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libXrender.so.1 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libfontconfig.so.1 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libresolv.so.2 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga-helper debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libbonoboui-2.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpopt.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libdl.so.2 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgnomecanvas-2.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgnomevfs-2.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpixman-1.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpangocairo-1.0.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libfreetype.so.6 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libICE.so.6 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libORBit-2.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on librt.so.1 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libxcb-render-util.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libxcb-render.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libgmodule-2.0.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libcairo.so.2 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libbonobo-2.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libSM.so.6 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libpng12.so.0 could be avoided if
Re: [Ekiga-devel-list] Unnecessary linked libraries
Hm... Here is the line for building ekiga, where -lz, -ldbus-1, -lpthread for ex. are present: g++ -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DORBIT2=1 -pthread -I/usr/include/libgnome-2.0 -I/usr/include/orbit-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0 -I/usr/include/gnome-keyring-1 -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0 -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/pixman-1 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/opal -DPTRACING -DNDEBUG -Os -g -fno-exceptions -felide-constructors -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/libxml2 -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -o ekiga accounts.o callbacks.o conf.o dialpad.o assistant.o main.o misc.o preferences.o tools.o statusicon.o statusmenu.o videoinput.o videooutput.o audiodev.o ekiga.o manager.o h323.o pcss.o sip-presentity.o sip-chat-simple.o sip-dialect.o sip.o opal-account.o opal-bank.o opal-call.o opal-codec-description.o opal-gmconf-bridge.o opal-main.o dbus.o -Wl,--export-dynamic -pthread -pthread ../lib/.libs/libekiga.a ../lib/engine/.libs/libekiga_engine.a /usr/lib/libfreetype.so -lz -lfontconfig -lpng12 -lxcb-render-util -lxcb-render -lxcb -lXrender -lX11 -lpixman-1 -lXv /usr/lib/libavahi-common.so /usr/lib/libavahi-client.so /usr/lib/libavahi-glib.so -lebook-1.2 -ledataserver-1.2 -llber -lldap /usr/lib/libgnomeui-2.so -lSM -lICE /usr/lib/libbonoboui-2.so /usr/lib/libgnomevfs-2.so /usr/lib/libgnomecanvas-2.so /usr/lib/libgnome-2.so /usr/lib/libpopt.so /usr/lib/libbonobo-2.so /usr/lib/libbonobo-activation.so /usr/lib/libORBit-2.so /usr/lib/libart_lgpl_2.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so /usr/lib/libpango-1.0.so /usr/lib/libcairo.so /usr/lib/libgconf-2.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libgmodule-2.0.so -ldbus-glib-1 -ldbus-1 /usr/lib/libgobject-2.0.so /usr/lib/libglib-2.0.so -ldl -lpthread -lopal -lpt /usr/lib/libsigc-2.0.so /usr/lib/libxml2.so -lresolv Damien Sandras wrote: Hi, I think they are dependancies of our dependancies. Le mardi 22 juillet 2008 à 11:13 +0200, Eugen Dedu a écrit : Hi, During building debian packages of ekiga, ptlib and opal, I receive many warnings about libraries linked uselessly. Can these libraries be removed from the list of linked libraries? I imagine however that they are needed for certain parameteres to configure, so if it is to complicated, let's stay with the actual code. I think (so not sure) that this might have negative influences to entering in debian testing of these packages: imagine that libz does not enter testing, this then prevents ekiga to enter testing, because its executable erroneously depends on it... Here are the warnings: for ekiga: dpkg-shlibdeps: warning: dependency on libz.so.1 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libdbus-1.so.3 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga-helper debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libbonobo-activation.so.4 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libXrender.so.1 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libfontconfig.so.1 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libresolv.so.2 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga-helper debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none of its symbols). dpkg-shlibdeps: warning: dependency on libbonoboui-2.so.0 could be avoided if debian/ekiga-snapshot/usr/bin/ekiga were not uselessly linked against it (they use none
Re: [Ekiga-devel-list] ekiga from 2008 06 16 failed to build (all arch)
yannick wrote:
g++ -DHAVE_CONFIG_H -I. -I.. -I../src -I../src/clients/
-I../src/components/ -I../src/devices/ -I../src/endpoints/ -I../src/gui/
-I../lib -I../lib/gmconf -I../lib/gui -I../lib/engine/
-I../lib/engine/gui/gtk-frontend -I../lib/engine/addressbook/skel
-I../lib/engine/chat/skel -I../lib/engine/presence/skel
-I../lib/engine/protocol/skel -I../lib/engine/protocol/sip
-I../lib/engine/videooutput/skel -I../lib/engine/videoinput/skel
-I../lib/engine/audioinput/skel -I../lib/engine/audiooutput/skel
-I../lib/engine/hal/skel -I../lib/engine/framework -I.. -DSCHEMA_AGE=61
-I../lib/engine/videooutput/common -I../lib/engine/videooutput/x
-DPNG_NO_MMX_CODE -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/pixman-1
-pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-DORBIT2=1 -pthread -DPNG_NO_MMX_CODE -I/usr/include/libgnome-2.0
-I/usr/include/orbit-2.0 -I/usr/include/gconf/2
-I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0
-I/usr/include/libgnomeui-2.0 -I/usr/include/libart-2.0
-I/usr/include/gnome-keyring-1 -I/usr/include/libbonoboui-2.0
-I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0
-I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0
-I/usr/include/freetype2 -I/usr/include/atk-1.0
-I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/libpng12
-I/usr/include/pixman-1 -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include-I/usr/include/opal -DPTRACING -DNDEBUG
-Os -g -fno-exceptions -felide-constructors -I/usr/include/sigc++-2.0
-I/usr/lib/sigc++-2.0/include -I/usr/include/libxml2 -g -O2 -Wall
-Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2
-Wfloat-equal -Wshadow -MT opal-call.o -MD -MP -MF .deps/opal-call.Tpo
-c -o opal-call.o `test -f 'endpoints/opal-call.cpp' || echo
'./'`endpoints/opal-call.cpp
endpoints/sip.cpp: In member function 'virtual void
Opal::Sip::CallProtocolManager::OnReceivedMESSAGE(OpalTransport, SIP_PDU)':
endpoints/sip.cpp:809: error: 'class SIPURL' has no member named
'AdjustForRequestURI'
endpoints/sip.cpp: In member function 'virtual void
Opal::Sip::CallProtocolManager::OnMessageFailed(const SIPURL,
SIP_PDU::StatusCodes)':
endpoints/sip.cpp:822: error: 'class SIPURL' has no member named
'AdjustForRequestURI'
endpoints/sip.cpp: In member function 'virtual void
Opal::Sip::CallProtocolManager::OnPresenceInfoReceived(const PString, const
PString, const PString)':
endpoints/sip.cpp:896: error: 'class SIPURL' has no member named
'AdjustForRequestURI'
make[4]: *** [sip.o] Error 1
As shown in
http://opalvoip.svn.sourceforge.net/viewvc/opalvoip/opal/trunk/src/sip/sippdu.cxx?r1=20328r2=20450,
rjongbloed has changed in opal:
void SIPURL::AdjustForRequestURI()
with
void SIPURL::Sanitise(UsageContext context)
Now the sanitise depends on the context. Therefore, someone must update
ekiga to use the new function with the correct parameter.
I propose the patch attached, but please review it carefully, since I do
not know the internals of opal...
For info, here are the UsageContext enum from opal/include/sip/sippdu.h:
enum UsageContext {
ExternalURI, /// URI used anywhere outside of protocol
RequestURI, /// Request-URI (after the INVITE)
ToURI,/// To header field
FromURI, /// From header field
ContactURI, /// Registration or Redirection Contact header field
RouteURI /// Dialog Contact header field, or Record-Route
header field
};
--
Eugen
--- ekiga.orig/src/endpoints/sip.cpp 2008-06-06 16:06:56.0 +0200
+++ ekiga/src/endpoints/sip.cpp 2008-06-18 16:10:38.0 +0200
@@ -805,8 +805,8 @@
msgData.SetAt (SIPURL (from).AsString (), val);
SIPURL uri = from;
+uri.Sanitise (FromURI);
std::string display_name = (const char *) uri.GetDisplayName ();
-uri.AdjustForRequestURI ();
std::string message_uri = (const char *) uri.AsString ();
std::string _message = (const char *) pdu.GetEntityBody ();
@@ -819,7 +819,7 @@
SIP_PDU::StatusCodes /*reason*/)
{
SIPURL to = messageUrl;
- to.AdjustForRequestURI ();
+ to.Sanitise (ToURI);
std::string uri = (const char *) to.AsString ();
runtime.run_in_main (sigc::bind (im_failed.make_slot (), uri,
_(Could not send message)));
@@ -892,10 +892,6 @@
std::string status;
std::string presence = presence-unknown;
- SIPURL sip_uri = SIPURL (user);
- sip_uri.AdjustForRequestURI ();
- std::string _uri = sip_uri.AsString ();
-
if (b.Find (Closed) != P_MAX_INDEX)
presence = presence-offline;
Re: [Ekiga-devel-list] test report: SVN trunk on Debian sid system
Lionel Elie Mamane wrote: On Mon, May 19, 2008 at 09:18:20PM +0200, Eugen Dedu wrote: Lionel Elie Mamane wrote: The Debian snapshots on snapshots.ekiga.net are quite old (several months), and don't install anymore on an up-to-date Debian sid (they just need a recompile against a new ABI-incompatible libldap), so I downloaded ptlib/opal/ekiga trunk and compiled them by hand. Any specific reason the snapshots are not updated anymore? I maintain ptlib/opal/ekiga packages for debian/ubuntu, you can find amd64 packages at http://eugen.dedu.free.fr. Ah, interesting. They seem to be compiled against lenny or sid; don't you hit the bug in http://sourceforge.net/tracker/index.php?func=detailaid=1966564group_id=204472atid=989748 ? Opal doesn't compile on amd64 for me, and I see nothing in your .diff.gz that would fix that. The error appears in file ptclib/podbc.cxx. This file is NOT compiled in my build. Do you use ./configure --enable-odbc? I use just --enable-oss --prefix=/usr. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga and x264 in Debian main
Luca Capello wrote: Hi there! On Sun, 18 May 2008 20:38:52 +0200, Eugen Dedu wrote: Matthias Schneider wrote: --- Eugen Dedu [EMAIL PROTECTED] schrieb am So, 18.5.2008: 1. I grouped all libpt-snapshot-plugins-* packages into one package, libpt-snapshot-plugins. Is this a good idea? I think stable has many separate plugins, since each plugin has different dependencies, at least I think so... In Kilian's debs and in actual debian ones, all libpt-plugins-* depend on the same packages. So it should be ok. Mmm, I haven't checked the .deb yet, but are you telling me that = [EMAIL PROTECTED]:~$ apt-cache search libpt-1.10.10-plugins libpt-1.10.10-plugins-alsa - Portable Windows Library Audio Plugin for the ALSA Interface libpt-1.10.10-plugins-avc - PWLib Video Plugin for IEEE1394 (FireWire) AVC devices libpt-1.10.10-plugins-dc - PWLib Video Plugin for IEEE1394 (Firewire) DC Devices libpt-1.10.10-plugins-oss - Portable Windows Library Audio Plugins for the OSS Interface libpt-1.10.10-plugins-v4l - Portable Windows Library Video Plugin for Video4Linux libpt-1.10.10-plugins-v4l2 - Portable Windows Library Video Plugin for Video4Linux v2 [EMAIL PROTECTED]:~$ = will be one single package? Please avoid that, at least because it's useless to install a V4L plugin when your webcam supports V4L2 only or having another OSS application when you want to get rid of it. Hi, Between : - having 6 packages, so wonder which one to choose (for ex. in my case by default v4l was installed, afterwards I saw that uvc works only in v4l2, reinstall v4l2, remove v4l...), complexify the dependencies etc. - having 1 package, with each plugin having about 150kB (IIRC) do you still choose the first? I think simpler is better, but if you really think it's better to have several packages, I will modify it. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] libavcodec.so avcodec.h
Matthias Apitz wrote:
Damien,
The Opal configuration proc looks for libavcodec.so which is in
FreeBSD in:
$ ls -l /usr/local/lib/libavcodec.so
lrwxr-xr-x 1 root wheel 21 21 mar 19:23 /usr/local/lib/libavcodec.so
- libavcodec.so.51.44.0
and the header file is /usr/local/include/ffmpeg/avcodec.h
the problem with the header file is that all the configure stuff
below opal/plugins/ (and as well the sources of the plugins is based
on that the header file is in #include libavcodec/avcodec.h
What would be the best strategy to fix this?
Use a patch like this.
--
Eugen
--- opal.orig/debian/patches/ffmpeg-includes.dpatch 1970-01-01 01:00:00.0 +0100
+++ opal/debian/patches/ffmpeg-includes.dpatch 2008-04-19 12:11:11.296526894 +0200
@@ -0,0 +1,116 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## libname.dpatch by Kilian Krause [EMAIL PROTECTED]
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: fix ffmpeg includes (work with versions of ffmpeg older than start 2008).
+
[EMAIL PROTECTED]@
+Index: opal/plugins/configure
+===
+--- opal/plugins/configure (revision 19925)
opal/plugins/configure (revision 19926)
+@@ -6857,7 +6857,7 @@
+ LIBS=$saved_LIBS
+ if test x${ffmpeg_libs} != xno; then
+
+-for ac_header in libavcodec/avcodec.h
++for ac_header in ffmpeg/avcodec.h
+ do
+ as_ac_Header=`echo ac_cv_header_$ac_header | $as_tr_sh`
+ if { as_var=$as_ac_Header; eval test \\${$as_var+set}\ = set; }; then
+@@ -7008,7 +7008,7 @@
+ cat confdefs.h conftest.$ac_ext
+ cat conftest.$ac_ext _ACEOF
+ /* end confdefs.h. */
+-#include libavcodec/avcodec.h
++#include ffmpeg/avcodec.h
+ #ifdef LIBAVCODEC_VERSION_INT
+#if LIBAVCODEC_VERSION_INT = ((5116)+(118)+0)
+ yes
+Index: opal/plugins/configure.ac
+===
+--- opal/plugins/configure.ac (revision 19925)
opal/plugins/configure.ac (revision 19926)
+@@ -378,12 +378,12 @@
+ AC_CHECK_LIB(avcodec, avcodec_init, [ffmpeg_libs=true], [ffmpeg_libs=false])
+ LIBS=$saved_LIBS
+ if test x${ffmpeg_libs} != xno; then
+-AC_CHECK_HEADERS([libavcodec/avcodec.h], [ffmpeg_headers=true], [ffmpeg_headers=false])
++AC_CHECK_HEADERS([ffmpeg/avcodec.h], [ffmpeg_headers=true], [ffmpeg_headers=false])
+ if test x${ffmpeg_headers} = xtrue; then
+
+ AC_MSG_CHECKING(for libavcodec version = 51.11.0)
+ AC_EGREP_CPP([yes],
+-[#include libavcodec/avcodec.h
++[#include ffmpeg/avcodec.h
+ #ifdef LIBAVCODEC_VERSION_INT
+#if LIBAVCODEC_VERSION_INT = ((5116)+(118)+0)
+ yes
+Index: opal/plugins/video/H.264/h264-x264.h
+===
+--- opal/plugins/video/H.264/h264-x264.h (revision 19925)
opal/plugins/video/H.264/h264-x264.h (revision 19926)
+@@ -56,9 +56,9 @@
+
+ extern C {
+ #ifdef _MSC_VER
+- #include libavcodec/avcodec.h
++ #include ffmpeg/avcodec.h
+ #else
+- #include libavcodec/avcodec.h
++ #include ffmpeg/avcodec.h
+ #endif
+ };
+
+Index: opal/plugins/video/H.263-1998/h263pframe.h
+===
+--- opal/plugins/video/H.263-1998/h263pframe.h (revision 19925)
opal/plugins/video/H.263-1998/h263pframe.h (revision 19926)
+@@ -28,7 +28,7 @@
+ #include rtpframe.h
+
+ extern C {
+-#include libavcodec/avcodec.h
++#include ffmpeg/avcodec.h
+ };
+
+ enum codecInFlags {
+Index: opal/plugins/video/H.263-1998/h263-1998.cxx
+===
+--- opal/plugins/video/H.263-1998/h263-1998.cxx (revision 19925)
opal/plugins/video/H.263-1998/h263-1998.cxx (revision 19926)
+@@ -55,7 +55,7 @@
+ #include mpi.h
+
+ extern C {
+-#include libavcodec/avcodec.h
++#include ffmpeg/avcodec.h
+ };
+
+ static FFMPEGLibrary FFMPEGLibraryInstance(CODEC_ID_H263P);
+Index: opal/plugins/video/common/dyna.h
+===
+--- opal/plugins/video/common/dyna.h (revision 19925)
opal/plugins/video/common/dyna.h (revision 19926)
+@@ -60,7 +60,7 @@
+ #include trace.h
+
+ extern C {
+-#include libavcodec/avcodec.h
++#include ffmpeg/avcodec.h
+ };
+
+ #include vector
+Index: opal/plugins/video/MPEG4-ffmpeg/mpeg4.cxx
+===
+--- opal/plugins/video/MPEG4-ffmpeg/mpeg4.cxx (revision 19925)
opal/plugins/video/MPEG4-ffmpeg/mpeg4.cxx (revision 19926)
+@@ -99,7 +99,7 @@
+ #include libavcodec/mpegvideo.h
+
+ #else /* LIBAVCODEC_HAVE_SOURCE_DIR */
+-#include libavcodec/avcodec.h
++#include ffmpeg/avcodec.h
+ #endif /* LIBAVCODEC_HAVE_SOURCE_DIR */
+ }
+
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
Re: [Ekiga-devel-list] NAT / STUN problem with the SVN compiled ekiga
Matthias Apitz wrote: El día Tuesday, May 20, 2008 a las 04:25:16PM +0200, Damien Sandras escribió: Le mardi 20 mai 2008 à 15:56 +0200, Matthias Apitz a écrit : El día Tuesday, May 20, 2008 a las 03:09:28PM +0200, Damien Sandras escribió: YES Removing /home/guru/.gconf/apps/ekiga Shutting down GConf daemon ...Done. $ ekiga Bad NAT Type it does not bring me into the NAT/STUN dialog; the resulting config looks like the attachment; It has not been reimplemented yet. Are you sure of your NAT config ? Damien, what do you mean with my NAT config? the one of ekiga or my firewall at all? my firewall is doing NAT hiding 10.0.1.0/24 (and other networks) behind the external NIC (193.31.11.193) of a IPFilter/IPnat based dual homed FreeBSD firewall box; it works well, I think; Can you check with an earlier version of Ekiga ? I would like to make sure it is not a bug in Ekiga (I do not see how it could be). sorry, but I have no older versions because I always to 'gmake install' after compiling all; how can I change in ekiga the NAT/STUN config? I can't see anything below ~/.gconf/apps/ekiga/... for this; There is nothing anymore because it is supposed to be automatic. yesterday evening it still worked; I did a SVN update this morning at 7:27 CEST: $ ls -lu svn.sh -rw-r--r-- 1 guru wheel 208 20 may 07:27 svn.sh of all (PTLib, Opal, Ekiga) and compiled all; I just came home from work to my smaller private network where it still worked last night; now it says; Bad NAT type In my case it prints Bad NAT type too, but it registers. After removing .gconf/apps/ekiga/general/nat/%gconf.xml, it does not print the message anymore. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga and x264 in Debian main (was Re: Trunk: OPAL Fax problem)
Matthias Schneider wrote: Quoting Eugen Dedu [EMAIL PROTECTED]: Matthias Schneider wrote: About the packages issue, I suppose that there should be packages like this: ekiga opal includes h.261 theora or depends opal-h261 oapl-theora ptlib opal-h263p depends libavcodec opal-mpeg4 depends libavcodec opal-h264 depends libavcodec libx264 opal / opal-theora depends libtheora ekiga/opal recommends opal-h263p, mpeg4, x264 The opal-x packages can have different states on ubuntu or debian, whether there is a non-free or whatever repository or some unofficial add-on repository... Hi, I put theora and h261 inside libopal. I generated a separate package for h264 (empty for the moment, I will fix it). Why do you propose separate packages for h263+ and mpeg4? Are they non-free (in debian)? -- Eugen Because they depend on libavcodec/ffmpeg, which are non-free as far as I know. Matthias libavcodec exists in debian too. So, except if you do not agree, I include them in opal (without creating other packages). From /usr/share/doc/ffmpeg/README.Debian: Summary of the patent issues with ffmpeg The only patents related to ffmpeg which seem to be enforced against open source software cover the following codec technologies and file formats: * MP3 encoding * AAC encoding * the ASF file format I did not activate MP3 encoding (through LAME) in libavcodec, nor AAC encoding (through FAAC). However, since I have found no real enforcement of the mysterious ASF file format patents, I did not deactivate ASF support in libavformat. See more details in the patents.txt file. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga and x264 in Debian main (was Re: Trunk: OPAL Fax problem)
Matthias Schneider wrote: Quoting Luca Capello [EMAIL PROTECTED]: Hi there! On Thu, 08 May 2008 11:47:38 +0200, Damien Sandras wrote: Le jeudi 08 mai 2008 à 11:45 +0200, Torsten Schlabach a écrit : Gismo / Luca wrote: If ekiga build-depends on x264 (which, BTW, is *still* not present as a Debian package, neither in non-free), ekiga itself will have to be put in non-free, which is something I won't prefer. No, we don't want that I think. It is a pwlib plugin, so it can be packaged separately, and that specific plugin can be put in non-free. Isn't instead an OPAL dependency? However, this won't solve anything, as far as I understood Matthias at [1]. But as a disclaimer, I haven't checked ekiga trunk lately. Please re-read the definition of the Debian categories [2]: a Debian package to be in main (thus distributed with official CDs) must build-depend only on software present in main. This means that if opal build-depends on x264 (which is, let's say, in non-free), then opal cannot be part of main. My previous statement that in this case opal (well, I wrote ekiga...) has to be put in non-free is wrong: opal can go into contrib, since opal itself is a free package which requires [...] a non-free package for compilation. As a result, ekiga has to be put in contrib, since ekiga build-depends on opal, which isn't in main. This situation will slow ekiga adoption, which is something I don't want to see. Thx, bye, Gismo / Luca Footnotes: [1] http://mail.gnome.org/archives/ekiga-devel-list/2008-May/msg00023.html [2] http://www.debian.org/doc/debian-policy/ch-archive.html#s-sections Sorry, forgot to send the following mail to the list...: About the packages issue, I suppose that there should be packages like this: ekiga opal includes h.261 theora or depends opal-h261 oapl-theora ptlib opal-h263p depends libavcodec opal-mpeg4 depends libavcodec opal-h264 depends libavcodec libx264 opal / opal-theora depends libtheora ekiga/opal recommends opal-h263p, mpeg4, x264 The opal-x packages can have different states on ubuntu or debian, whether there is a non-free or whatever repository or some unofficial add-on repository... Hi, I am doing the proposed modifications, thanks for the idea. 1. I grouped all libpt-snapshot-plugins-* packages into one package, libpt-snapshot-plugins. 2. Does opal, which is a library, depend on libspeex, or ekiga? 3. For opal, I see the following video codecs: libopal-snapshot/usr/lib/ptlib-snapshot/opal-3.3.0/codecs/video: total 776 -rw-r--r-- 1 dedu 344240 May 17 22:16 h261-vic_video_pwplugin.so -rw-r--r-- 1 dedu 107144 May 17 22:16 h263-1998_video_pwplugin.so -rw-r--r-- 1 dedu 63000 May 17 22:16 h263-ffmpeg_video_pwplugin.so -rw-r--r-- 1 dedu 79352 May 17 22:16 h264_video_pwplugin.so -rwxr-xr-x 1 dedu 40168 May 17 22:16 h264_video_pwplugin_helper -rw-r--r-- 1 dedu 81624 May 17 22:16 mpeg4-ffmpeg_video_pwplugin.so -rw-r--r-- 1 dedu 65088 May 17 22:16 theora_video_pwplugin.so Should both h263-1998 and h263-ffmpeg be put in the opal-h263 package? What's the difference between them? Is there one better than another, and the other can be removed? Also, is the h264_video_pwplugin_helper file useful or is a packaging error? Finally, is it possible to compile h264 only? If yes, what is the ./configure or ./autogen.sh command line? I will look myself too, but if you already know the answer, please tell me. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Ekiga and x264 in Debian main (was Re: Trunk: OPAL Fax problem)
Hi Matthias, Thanks for answer. See below. Matthias Schneider wrote: Hi Eugen, see my answers inline. --- Eugen Dedu [EMAIL PROTECTED] schrieb am So, 18.5.2008: Von: Eugen Dedu [EMAIL PROTECTED] Betreff: Re: [Ekiga-devel-list] Ekiga and x264 in Debian main (was Re: Trunk: OPAL Fax problem) An: Ekiga development mailing list ekiga-devel-list@gnome.org Datum: Sonntag, 18. Mai 2008, 15:53 Matthias Schneider wrote: Quoting Luca Capello [EMAIL PROTECTED]: Hi there! On Thu, 08 May 2008 11:47:38 +0200, Damien Sandras wrote: Le jeudi 08 mai 2008 à 11:45 +0200, Torsten Schlabach a écrit : Gismo / Luca wrote: If ekiga build-depends on x264 (which, BTW, is *still* not present as a Debian package, neither in non-free), ekiga itself will have to be put in non-free, which is something I won't prefer. No, we don't want that I think. It is a pwlib plugin, so it can be packaged separately, and that specific plugin can be put in non-free. Isn't instead an OPAL dependency? However, this won't solve anything, as far as I understood Matthias at [1]. But as a disclaimer, I haven't checked ekiga trunk lately. Please re-read the definition of the Debian categories [2]: a Debian package to be in main (thus distributed with official CDs) must build-depend only on software present in main. This means that if opal build-depends on x264 (which is, let's say, in non-free), then opal cannot be part of main. My previous statement that in this case opal (well, I wrote ekiga...) has to be put in non-free is wrong: opal can go into contrib, since opal itself is a free package which requires [...] a non-free package for compilation. As a result, ekiga has to be put in contrib, since ekiga build-depends on opal, which isn't in main. This situation will slow ekiga adoption, which is something I don't want to see. Thx, bye, Gismo / Luca Footnotes: [1] http://mail.gnome.org/archives/ekiga-devel-list/2008-May/msg00023.html [2] http://www.debian.org/doc/debian-policy/ch-archive.html#s-sections Sorry, forgot to send the following mail to the list...: About the packages issue, I suppose that there should be packages like this: ekiga opal includes h.261 theora or depends opal-h261 oapl-theora ptlib opal-h263p depends libavcodec opal-mpeg4 depends libavcodec opal-h264 depends libavcodec libx264 opal / opal-theora depends libtheora ekiga/opal recommends opal-h263p, mpeg4, x264 The opal-x packages can have different states on ubuntu or debian, whether there is a non-free or whatever repository or some unofficial add-on repository... Hi, I am doing the proposed modifications, thanks for the idea. 1. I grouped all libpt-snapshot-plugins-* packages into one package, libpt-snapshot-plugins. Is this a good idea? I think stable has many separate plugins, since each plugin has different dependencies, at least I think so... In Kilian's debs and in actual debian ones, all libpt-plugins-* depend on the same packages. So it should be ok. 2. Does opal, which is a library, depend on libspeex, or ekiga? OPAL does, for echo cancelation, and of course the speex plugin does for the speex codec itself. Ok. 3. For opal, I see the following video codecs: libopal-snapshot/usr/lib/ptlib-snapshot/opal-3.3.0/codecs/video: total 776 -rw-r--r-- 1 dedu 344240 May 17 22:16 h261-vic_video_pwplugin.so -rw-r--r-- 1 dedu 107144 May 17 22:16 h263-1998_video_pwplugin.so -rw-r--r-- 1 dedu 63000 May 17 22:16 h263-ffmpeg_video_pwplugin.so -rw-r--r-- 1 dedu 79352 May 17 22:16 h264_video_pwplugin.so -rwxr-xr-x 1 dedu 40168 May 17 22:16 h264_video_pwplugin_helper -rw-r--r-- 1 dedu 81624 May 17 22:16 mpeg4-ffmpeg_video_pwplugin.so -rw-r--r-- 1 dedu 65088 May 17 22:16 theora_video_pwplugin.so Should both h263-1998 and h263-ffmpeg be put in the opal-h263 package? What's the difference between them? Is there one better than another, and the other can be removed? Consider them different codecs. H.263+ (1998) is the newer one, not compatible withe H.263 (at least their encapsulation). H.263 has been declared obsolete by IETF, but not by ITU. H.263 depends on a hackish patched version of ffmpeg, while all the other codecs depend on normal ffmpeg. I propose to leave it out for now (and stick only to H.263+), if it is ok for damien. Ok, I wait Damien's reply. Also, is the h264_video_pwplugin_helper file useful or is a packaging error? Both h264_video_pwplugin.so and h264_video_pwplugin_helper belong to the h264 package. The helper is the gpled executable that loads the x264 library. Ok. Finally, is it possible to compile h264 only? If yes, what is the ./configure or ./autogen.sh command line? I will look myself too, but if you already know the answer, please tell me. No, not really... Does this help in the package building? I will probably revise the build system in the future, but I do not know
Re: [Ekiga-devel-list] Script to compile 3.0 SVN version on Linux
Torsten Schlabach wrote: Hi all! Does anyone have a script which simple does a clean checkout of - PTLib - OPAL - Eikiga from SVN and builds it all the way through on Linux? Wouldn't it make sense to make some kind of umbrella Makefile as it exists for the win32 build? In case anyone has such a script, he or she might be so kind and post it? Hi, The following script is what I use to update the debs of ptlib, opal and ekiga. I have three directories with the three co. I execute the script and it generates all the debs. The three *.diff are identical to the three *.diff.gz you find at http://eugen.dedu.free.fr/ekiga. Hope it will be useful to you. There are also scripts on the wiki pages. -- Eugen build.sh Description: Bourne shell script ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Compilation error
Fabrice ALPHONSO wrote: Hi guys, Ekiga fails to compile after some change in ptlib/opal. Revision 20199 of ptlib/opal (the last three or four revisions were about T.38 protocol/capacity it seems) Revision 6244 of ekiga. The error appears in ekiga's compilation (both ptlib and opal compiled and installed fine). here is the error I had : /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libopal.so: undefined reference to `T38_UDPTLPacket::Decode(PASN_Stream)' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libopal.so: undefined reference to `vtable for T38_UDPTLPacket_error_recovery' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libopal.so: undefined reference to `T38_UDPTLPacket::T38_UDPTLPacket(unsigned int, PASN_Object::TagClass)' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libopal.so: undefined reference to `T38_UDPTLPacket_error_recovery_secondary_ifp_packets::operator[](int) const' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libopal.so: undefined reference to `vtable for T38_UDPTLPacket_primary_ifp_packet' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libopal.so: undefined reference to `T38_UDPTLPacket::Encode(PASN_Stream) const' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libopal.so: undefined reference to `T38_UDPTLPacket_error_recovery::operator T38_UDPTLPacket_error_recovery_secondary_ifp_packets()' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libopal.so: undefined reference to `vtable for T38_UDPTLPacket' collect2: ld returned 1 exit status make[3]: *** [ekiga] Erreur 1 make[3]: quittant le répertoire « /usr/local/src/ekiga/src » make[2]: *** [all] Erreur 2 make[2]: quittant le répertoire « /usr/local/src/ekiga/src » make[1]: *** [all-recursive] Erreur 1 make[1]: quittant le répertoire « /usr/local/src/ekiga » make: *** [all] Erreur 2 For me, opal compilation error: /home/dedu/softs/ekiga/opal/include/asn/t38.h:169: undefined reference to `vtable for T38_UDPTLPacket_error_recovery' /home/dedu/softs/ekiga/opal/lib/notrace/libopal_s.a(t38proto.o): In function `~T38_UDPTLPacket': /home/dedu/softs/ekiga/opal/include/asn/t38.h:482: undefined reference to `vtable for T38_UDPTLPacket' collect2: ld returned 1 exit status make[2]: *** [obj_linux_x86_64_n/simpleopal] Error 1 make[2]: Leaving directory `/home/dedu/softs/ekiga/opal/samples/simple' HTH too :o) -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] .deb for ptlib, opal, ekiga yesterday SVN
Hi, yannick wrote: Le mardi 22 avril 2008 à 17:32 +0200, Damien Sandras a écrit : Hi, Le mardi 22 avril 2008 à 17:21 +0200, Eugen Dedu a écrit : Damien Sandras wrote: Le dimanche 20 avril 2008 à 22:38 +0200, Eugen Dedu a écrit : [...] Let me know what do you think. Do you think you will build them regularly or run some sort of cron ? If it is the case we could resuscitate snapshots.seconix.com with at least those packs. (I would download them overnight daily from your box). Yes, I would be glad to build them regularly! Kilian has sent me his script to help him building ekigaCo. However, for the moment I prefer to do it manually. I will inform you when I re-build. Good, once they are built regularly, we can mirror them. Please keep me informed about when you want to do it. We can arrange things with Yannick and Jan so that it is done on a daily basis. Hi, I plan to write this evening a simple script to rebuild them, and cron it regularly (each 1-3 days). I will do it for ubuntu too, since i saw in Kilian's diff.gz the modifications needed. I plan to maintain sid and gutsy, is it useful to have more? For Ubuntu, perhaps, for Debian, SID is plain enough. Yannick, what do you think ? For ubuntu, gutsy will be replaced in 2 days by the new LTS Hardy Heron (Long Time Support). Most of the users will move to that (including corporates). This is the target for ubuntu. From my own testing, the process is the same as Gutsy, this should be an easy move. If you want you can include the next one (i dont remember the name) for the reason it will be the real target for the 3.0 release (this next ubuntu is due in october 2008); it will help testing everything is fine with it. I can create and check the .diff.gz for debian sid (my distro). For ubuntu, I can only create them by looking at the differences in previous .diff.gz, but I cannot test them/build debs, as I do not have ubuntu. I've not tested your packs yet, just to know: did you signed them with a pgp key? Not yet, I haven't used it until now... I will use it this evening if I have the time, otherwise tomorrow. -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] A few usability improvements in ekiga SVN
Hello, Damien Sandras wrote: Hello again, Le samedi 19 avril 2008 à 19:32 +0200, Eugen Dedu a écrit : Hi, During configuration assistant: - General-Sound Events: I don't know why, voice mail and instant msg sounds point to a inexistent wav file in /usr/local/share/..., instead of /usr/share/... After setting them to a valid directory/file, it is ok Not here. Wouldn't it be a packaging thing or an old setting ? Probably an old setting... We wait and see if others complain. Thanks for your work and remarks ! Thanks for *your* work! -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] .deb for ptlib, opal, ekiga yesterday SVN
Damien Sandras wrote:
Hi,
Le samedi 19 avril 2008 à 16:26 +0200, Eugen Dedu a écrit :
Hi,
To install them, better (IMO) remove before any libpt*, libopal*, ekiga*
packages on the machine.
Manual procedure I used to create the packages, given that .diff.gz are
provided:
svn co https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/trunk
ptlib
svn co https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/opal/trunk opal
svn co http://svn.gnome.org/svn/ekiga/trunk ekiga
for i in ptlib opal ekiga; do
cd $i
if [ $i -ne 'ekiga' ]; then svn2cl; fi
find . -name .svn -exec rm -rf {} \; # -- don't know if really needed
cd ..
cp -a $i $i.orig # -- allows to create the .diff.gz file
cd $i
patch -p1 ../$i*.diff.gz # the .diff.gz are provided
debuild -us -uc
cd ..
done
Of course, the version of packages (e.g. -20080418) should be updated
according to the downloading date.
TODO for deb packages:
- revisit debian/copyright, seems that some files in ptlib (at least)
have specific copyrights
- revisit debian/templates
- configure.dpatch in ptlib: is it really needed, Kilian?
- and others
Let me know what do you think.
Do you think you will build them regularly or run some sort of cron ?
If it is the case we could resuscitate snapshots.seconix.com with at
least those packs. (I would download them overnight daily from your
box).
Yes, I would be glad to build them regularly! Kilian has sent me his
script to help him building ekigaCo. However, for the moment I prefer
to do it manually. I will inform you when I re-build.
(PS Exactly when all was finished, I executed an rm instead of mv, and I
lost the opal*diff.gz file :o(; it took my 2 hours to recreate it. Do
you know that you can recover files simply with # cat
/dev/sda3|strings|grep what you are looking for?)
Argh, I did not know that tip.
Thanks a lot anyway, you did a great job!
Thanks, glad to help ekiga!
--
Eugen
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] .deb for ptlib, opal, ekiga yesterday SVN
Matthias Schneider wrote: Quoting Damien Sandras [EMAIL PROTECTED]: Hi, Le samedi 19 avril 2008 à 16:26 +0200, Eugen Dedu a écrit : Hi, [deleted...] (PS Exactly when all was finished, I executed an rm instead of mv, and I lost the opal*diff.gz file :o(; it took my 2 hours to recreate it. Do you know that you can recover files simply with # cat /dev/sda3|strings|grep what you are looking for?) Could you perhaps send me the diffs needed for opal and ptlib? Probably I will be revising the build system, so I would like to integrate Kilian's requirements as well... They are at http://eugen.dedu.free.fr/ekiga/ Do you need help for revising the build system? Cheers, -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] .deb for ptlib, opal, ekiga yesterday SVN
Hi,
I have finally managed to create .debs for ptlib, opal, ekiga and start
ekiga!!! They use yesterday SVN. They are based on Kilian's deb
.diff.gz, with modifications for current SVN versions. I put them at
http://eugen.dedu.free.fr/ekiga.
To install them, better (IMO) remove before any libpt*, libopal*, ekiga*
packages on the machine.
Manual procedure I used to create the packages, given that .diff.gz are
provided:
svn co https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/ptlib/trunk
ptlib
svn co https://opalvoip.svn.sourceforge.net/svnroot/opalvoip/opal/trunk opal
svn co http://svn.gnome.org/svn/ekiga/trunk ekiga
for i in ptlib opal ekiga; do
cd $i
if [ $i -ne 'ekiga' ]; then svn2cl; fi
find . -name .svn -exec rm -rf {} \; # -- don't know if really needed
cd ..
cp -a $i $i.orig # -- allows to create the .diff.gz file
cd $i
patch -p1 ../$i*.diff.gz # the .diff.gz are provided
debuild -us -uc
cd ..
done
Of course, the version of packages (e.g. -20080418) should be updated
according to the downloading date.
TODO for deb packages:
- revisit debian/copyright, seems that some files in ptlib (at least)
have specific copyrights
- revisit debian/templates
- configure.dpatch in ptlib: is it really needed, Kilian?
- and others
Let me know what do you think.
(PS Exactly when all was finished, I executed an rm instead of mv, and I
lost the opal*diff.gz file :o(; it took my 2 hours to recreate it. Do
you know that you can recover files simply with # cat
/dev/sda3|strings|grep what you are looking for?)
Greetings,
--
Eugen
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] beta or -beta?
Hi,
I have succeeded to create .deb packages of ptlib on my machine. I try
now opal, afterwards ekiga. One of the bugs preventing the automatic
generation is that, in ptlib/trunk, in one file the suffix of the
library is 'beta', and in another is '-beta':
- make/common.mak:
BUILD_TYPE:=$(strip $(subst \#define,,$(subst BUILD_TYPE,,\
$(subst AlphaCode,alpha,$(subst BetaCode,beta,$(subst
ReleaseCode,.,\
- configure.ac and configure:
BUILD_TYPE=`cat ${PTLIBDIR}/version.h | grep BUILD_TYPE | cut -f 3 -d '
' | sed 's/BetaCode/-beta/' | sed 's/AlphaCode/-alpha/' | sed
's/ReleaseCode/\./'`
Note the replacing of BetaCode with beta and -beta (the same for alpha).
As info, in opal configure* uses -beta, and there is no make/common.mak
file.
Could you fix this bug please? It really eases the deb building...
--
Eugen Dedu
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
[Ekiga-devel-list] Building trunk in home 2
://www.gnome.org/projects/gconf/) or the mailing list archives for more information (http://mail.gnome.org) about this problem. and the following errors on the terminal: snoopy:~/softs/ekiga$ src/ekiga audiooutput-core.cpp(392) AudioOutputCore Closing current device audioinput-core.cpp(322)AudioInputCore Stopping Stream audioinput-core.cpp(325)AudioInputCore Trying to stop stream in wrong state (ekiga:21352): GConf-CRITICAL **: gconf_value_get_list: assertion `value != NULL' failed (ekiga:21352): GConf-CRITICAL **: gconf_value_get_int: assertion `value != NULL' failed (ekiga:21352): GConf-CRITICAL **: gconf_value_get_int: assertion `value != NULL' failed (ekiga:21352): GConf-CRITICAL **: gconf_value_get_int: assertion `value != NULL' failed (ekiga:21352): GConf-CRITICAL **: gconf_value_get_int: assertion `value != NULL' failed (ekiga:21352): GConf-CRITICAL **: gconf_value_get_string: assertion `value != NULL' failed (ekiga:21352): GConf-CRITICAL **: gconf_value_get_int: assertion `value != NULL' failed audiooutput-core.cpp(158) AudioOutputCore Setting device[0]: Default/Default/Default audiooutput-core.cpp(158) AudioOutputCore Setting device[1]: Default/Default/Default audioinput-core.cpp(209)AudioInputCore Setting device: Default/Default/Default Segmentation fault But I do not have such a key: snoopy:~$ grep -r test_age .gconf I looked at http://www.ekiga.org/index.php?rub=3pos=0faqpage=x201.html#AEN264 (GConf errors on ekiga): - killing gconf doesn't fix the problem - /etc/gconf/gconf.xml.defaults/ directory is already 755 (4755??) - what are the gconf flags to compile ekiga? I have compiled with ./autogen.sh --disable-doc --disable-avahi --disable-dbus --prefix=`pwd` and ekiga has gconf support: snoopy:~/softs/ekiga$ grep -i gconf config.h /* GConf support */ #define HAVE_GCONF 1 - as about gconf working properly, I haven't touch at it after installing a fresh debian system, so I suppose it's ok I tried also (http://forum.ubuntu-fr.org/viewtopic.php?id=154833): gconftool-2 -u /apps/ekiga/general/gconf_test_age killall -9 gconfd-2 (without sudo) I started ekiga as root also, without succes... I looked at the code - src/gui/main.cpp:4385, gnomemeeting_conf_check () returns FALSE - src/gui/conf.cpp:205, gnomemeeting_conf_check calls gm_conf_get_int (...test_age), which in turn calls gconf_client_get_int. This function returns 0, so ekiga stops with error. But this function returns 0 not only when there is an error, but also when the key test_age does not exist (or have a non integer type), which is my case. Should this key exist?? Why does ekiga stops if this key does not have a certain value? As a workaround, I removed the tests whether this key exists or not. 8. The config assistant appears, but a few seconds later the program receives seg fault. Here is the backtrace with gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b600e2c6120 (LWP 5105)] 0x2b6007ee0090 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x2b6007ee0090 in strlen () from /lib/libc.so.6 #1 0x007e1cd7 in motion_detection_cb (data=0x14ae7b0) at /usr/include/c++/4.2/bits/char_traits.h:258 #2 0x2b60068c581b in ?? () from /usr/lib/libglib-2.0.so.0 #3 0x2b60068c50f2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x2b60068c8396 in ?? () from /usr/lib/libglib-2.0.so.0 #5 0x2b60068c8657 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #6 0x2b6004bfdb63 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x007e08c8 in main (argc=value optimized out, argv=value optimized out, envp=value optimized out) at gui/main.cpp:4488 (gdb) As threads are involved, I do not know if this bt is really useful. I stop here my investigation, because I do not know if the segfault is due to gconf code or not. Best regards, -- Eugen Dedu ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Building trunk in home 2
Damien Sandras wrote: Hi, Le dimanche 13 avril 2008 à 12:52 +0200, Eugen Dedu a écrit : Hi, I am compiling ptlib, opal and ekiga, all from svn of yesterday. My final goal (I hope to reach it) is to build very soon (unofficial) debian packages for them. Thanks to the wiki page and previous post Good news ! I have just sent an email to Kilian Krause to know if he is willing to put them in the experimental debian distro (if I succeed to create them). This comes from the file display-core.h: #include glib.h //FIXME #include ptbuildopts.h #include ptlib.h 3. The same compilation error (ptlib.h not found) appears when compiling files in directories: /home/dedu/softs/ekiga/lib/engine/vidinput, subdirs skel, mlogo, ptlib /home/dedu/softs/ekiga/lib/engine/audioinput, subdirs skel, mlogo, ptlib /home/dedu/softs/ekiga/lib/engine/audiooutput, subdirs skel, mlogo, ptlib As a workaround, I have added -I/home/dedu/softs/ptlib/include at the end of the line CXXFLAGS=... in the Makefile of these directories. 4. During linking, it uses -lopal and -lpt, but the libraries in pt and opal have other (long) names. To cope with this, I executed: snoopy:~/softs/opal/lib$ ln -s libopal_linux_x86_64_r_s.a libopal.a snoopy:~/softs/ptlib/lib$ ln -s libpt_linux_x86_64_r_s.a libpt.a Are you sure you did a make install in DESTDIR ? It looks like you did not run it. No, I didn't executed it. I thought that make install just moves them in the corresponding directory, but now I know that I am wrong (it creates links too). So I changed prefix to `pwd`/../bins and executed make install for ptlib and opal. .h and .so are put inside. However, all the compilation errors about ptlib.h remain (points 2 and 3). The directory for ptlib is not included in the compilation command line of display-core.cpp: g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../lib/gmconf -I../../../../lib/engine/include -I../../../../lib/engine/framework -I../../../../lib/engine/display/skel -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT display-core.lo -MD -MP -MF .deps/display-core.Tpo -c ../../../../lib/engine/display/skel/display-core.cpp -fPIC -DPIC -o .libs/display-core.o [...] 8. The config assistant appears, but a few seconds later the program receives seg fault. Here is the backtrace with gdb: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x2b600e2c6120 (LWP 5105)] 0x2b6007ee0090 in strlen () from /lib/libc.so.6 (gdb) bt #0 0x2b6007ee0090 in strlen () from /lib/libc.so.6 #1 0x007e1cd7 in motion_detection_cb (data=0x14ae7b0) at /usr/include/c++/4.2/bits/char_traits.h:258 #2 0x2b60068c581b in ?? () from /usr/lib/libglib-2.0.so.0 #3 0x2b60068c50f2 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x2b60068c8396 in ?? () from /usr/lib/libglib-2.0.so.0 #5 0x2b60068c8657 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #6 0x2b6004bfdb63 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x007e08c8 in main (argc=value optimized out, argv=value optimized out, envp=value optimized out) at gui/main.cpp:4488 Yannick reported me that one too. That's weird. I will have a look now. Thanks. -- Eugen Dedu ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Building trunk in home 2
Eugen Dedu wrote: Damien Sandras wrote: Hi, Le dimanche 13 avril 2008 à 12:52 +0200, Eugen Dedu a écrit : Hi, This comes from the file display-core.h: #include glib.h //FIXME #include ptbuildopts.h #include ptlib.h 3. The same compilation error (ptlib.h not found) appears when compiling files in directories: /home/dedu/softs/ekiga/lib/engine/vidinput, subdirs skel, mlogo, ptlib /home/dedu/softs/ekiga/lib/engine/audioinput, subdirs skel, mlogo, ptlib /home/dedu/softs/ekiga/lib/engine/audiooutput, subdirs skel, mlogo, ptlib As a workaround, I have added -I/home/dedu/softs/ptlib/include at the end of the line CXXFLAGS=... in the Makefile of these directories. 4. During linking, it uses -lopal and -lpt, but the libraries in pt and opal have other (long) names. To cope with this, I executed: snoopy:~/softs/opal/lib$ ln -s libopal_linux_x86_64_r_s.a libopal.a snoopy:~/softs/ptlib/lib$ ln -s libpt_linux_x86_64_r_s.a libpt.a Are you sure you did a make install in DESTDIR ? It looks like you did not run it. No, I didn't executed it. I thought that make install just moves them in the corresponding directory, but now I know that I am wrong (it creates links too). So I changed prefix to `pwd`/../bins and executed make install for ptlib and opal. .h and .so are put inside. However, all the compilation errors about ptlib.h remain (points 2 and 3). The directory for ptlib is not included in the compilation command line of display-core.cpp: g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../lib/gmconf -I../../../../lib/engine/include -I../../../../lib/engine/framework -I../../../../lib/engine/display/skel -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -Wall -Wextra -Winit-self -Wswitch-default -Wswitch-enum -Wstrict-aliasing=2 -Wfloat-equal -Wshadow -MT display-core.lo -MD -MP -MF .deps/display-core.Tpo -c ../../../../lib/engine/display/skel/display-core.cpp -fPIC -DPIC -o .libs/display-core.o Really sorry. Yannick, in his previous post (http://mail.gnome.org/archives/ekiga-devel-list/2008-April/msg00092.html), has already seen this, because he used: export CPPFLAGS=-I$HOME/build-ekiga-svn/usr/include Of course, this does not mean that this is not a bug... -- Eugen Dedu ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
