Le lundi 02 mars 2009 à 15:35 +0100, Alec Leamas a écrit : > Eugen Dedu wrote: > > Alec Leamas wrote: > >> Damien Sandras wrote: > >>> Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit : > >>> > >>>> Eugen Dedu wrote: > >>>> > >>>>> Eugen Dedu wrote: > >>>>> > >>>>>> Damien Sandras wrote: > >>>>>> > >>>>>>> Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit : > >>>>>>> > >>>>>>>> Damien Sandras wrote: > >>>>>>>> > >>>>>>>>> Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a > >>>>>>>>> écrit : > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Damien Sandras <dsand...@seconix.com> writes: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a > >>>>>>>>>>> écrit : > >>>>>>>>>>> > >>>>>>>>>>>> I have run through the configuration assistant thing from > >>>>>>>>>>>> start to > >>>>>>>>>>>> finish. I can call the 5...@ekiga.net echo test and that > >>>>>>>>>>>> works just fine. > >>>>>>>>>>>> However, calling the 5...@ekiga.net callback service has it > >>>>>>>>>>>> hang up on me > >>>>>>>>>>>> and then ... nothing, though the -d 5 output shows that it > >>>>>>>>>>>> is indeed > >>>>>>>>>>>> getting a callback initiated from from sip:5...@ekiga.net > >>>>>>>>>>>> which is then > >>>>>>>>>>>> aborted. I am behind NAT and the router forwards incoming > >>>>>>>>>>>> UDP from port > >>>>>>>>>>>> 5060 to 5100 to the machine I'm using and acts as a gateway > >>>>>>>>>>>> to let all > >>>>>>>>>>>> my outgoing packets out. > >>>>>>>>>>>> > >>>>>>>>>>>> Should I gzip my -d 4 output and send it to somebody? I can > >>>>>>>>>>>> also sniff > >>>>>>>>>>>> packets and send pcap files. I use Debian; software > >>>>>>>>>>>> versions are, > >>>>>>>>>>>> > >>>>>>>>>>> There is a known problem with incoming calls and the current > >>>>>>>>>>> snapshot. I > >>>>>>>>>>> will fix it this week-end. > >>>>>>>>>>> > >>>>>>>>>> Now with the 20090225 one, the incoming call does arrive > >>>>>>>>>> (yay!), I hit > >>>>>>>>>> `accept', and it segfaults. > >>>>>>>>>> > >>>>>>>>>> I can still send my -d 4 output to somebody. (-: > >>>>>>>>>> > >>>>>>>>> A gdb backtrace would be more useful. > >>>>>>>>> > >>>>>>>> waiting for some kind of customer "service", taking a backtrace > >>>>>>>> (yes, same problem, trunk as of yesterday). > >>>>>>>> > >>>>>>> Despite trying 50 times, I can not reproduce it. Are you sure > >>>>>>> something > >>>>>>> is not corrupted? > >>>>>>> > >>>>>>> Eugen, can you reproduce it? > >>>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Sorry for taking so much time to reply. > >>>>>> > >>>>>> Very interesting, when I call 520, I receive the call and it > >>>>>> works (I > >>>>>> have audio conversation). I use on debian > >>>>>> ii ekiga-snapshot 0-20090226-1 H.323 and SIP > >>>>>> compatible VoIP > >>>>>> client - svn version > >>>>>> > >>>>>> > >>>>>>> configure: dummy > >>>>>>> export PTLIBDIR=$$PWD; \ > >>>>>>> ./configure \ > >>>>>>> --prefix=/usr \ > >>>>>>> --libdir=/usr/lib64 \ > >>>>>>> --enable-debug \ > >>>>>>> --enable-tracing \ > >>>>>>> --disable-static \ > >>>>>>> --enable-plugins \ > >>>>>>> --disable-oss \ > >>>>>>> --enable-v4l2 \ > >>>>>>> --disable-avc \ > >>>>>>> --disable-v4l > >>>>>>> > >>>>>> For info, I use much less configure options, only prefix and > >>>>>> enable-v4l > >>>>>> for ptlib I think, the other ones are by default. (But I do not > >>>>>> think > >>>>>> this is the problem.) > >>>>>> > >>>>>> By the way, does someone know how we can show the default options > >>>>>> when > >>>>>> running ./configure --help (for ex.)? Instead of putting them in > >>>>>> the > >>>>>> wiki, better to automatise the process by pushing them in the > >>>>>> source code. > >>>>>> > >>>>>> > >>>>>>> ================ Final configuration =================== > >>>>>>> Installing into prefix : /usr > >>>>>>> > >>>>>>> > >>>>>> [...] > >>>>>> > >>>>>>> libnotify support : disabled > >>>>>>> > >>>>>> Maybe it's because libnotify disabled?! I have it enabled, and I > >>>>>> have: > >>>>>> ii libnotify-dev 0.4.4-3 sends desktop > >>>>>> notifications to > >>>>>> a notification daemon > >>>>>> ii libnotify1 0.4.4-3 sends desktop > >>>>>> notifications to > >>>>>> a notification daemon > >>>>>> > >>>>> In fact, it cannot be because of libnotify, because Mark Carroll > >>>>> has the same problem and he uses snapshots, which use libnotify... > >>>>> > >>>>> > >>>> My bad, thou shall not guess. I just compiled a version w > >>>> libnotify, same problem & crash. Relevant thread from gdb: > >>>> > >>>> Program received signal SIGSEGV, Segmentation fault. > >>>> 0x00000037b3429a8c in g_type_check_instance_cast () > >>>> from /lib64/libgobject-2.0.so.0 > >>>> > >>>> [cut] > >>>> > >>>> Thread 1 (Thread 0x7ffff6b0f7b0 (LWP 23589)): > >>>> #0 0x00000037b3429a8c in g_type_check_instance_cast () > >>>> from /lib64/libgobject-2.0.so.0 > >>>> #1 0x00000000004aa1da in closed_cb (main_window=0x2) at > >>>> gui/main.cpp:2759 > >>>> #2 0x00000037b340b7dd in g_closure_invoke () from > >>>> /lib64/libgobject-2.0.so.0 > >>>> #3 0x00000037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 > >>>> #4 0x00000037b3422b68 in g_signal_emit_valist () > >>>> from /lib64/libgobject-2.0.so.0 > >>>> #5 0x00000037b3423093 in g_signal_emit () from > >>>> /lib64/libgobject-2.0.so.0 > >>>> #6 0x0000003167603929 in ?? () from /usr/lib64/libnotify.so.1 > >>>> #7 0x0000003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2 > >>>> #8 0x00000037b340b7dd in g_closure_invoke () from > >>>> /lib64/libgobject-2.0.so.0 > >>>> #9 0x00000037b34214bd in ?? () from /lib64/libgobject-2.0.so.0 > >>>> #10 0x00000037b3422b68 in g_signal_emit_valist () > >>>> from /lib64/libgobject-2.0.so.0 > >>>> #11 0x00000037b3423093 in g_signal_emit () from > >>>> /lib64/libgobject-2.0.so.0 > >>>> #12 0x0000003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2 > >>>> #13 0x0000003b98c0ef7b in dbus_connection_dispatch () > >>>> from /lib64/libdbus-1.so.3 > >>>> #14 0x0000003b99809765 in ?? () from /usr/lib64/libdbus-glib-1.so.2 > >>>> #15 0x00000037b2c3779b in g_main_context_dispatch () > >>>> from /lib64/libglib-2.0.so.0 > >>>> #16 0x00000037b2c3af6d in ?? () from /lib64/libglib-2.0.so.0 > >>>> #17 0x00000037b2c3b49d in g_main_loop_run () from > >>>> /lib64/libglib-2.0.so.0 > >>>> #18 0x00000037b99238a7 in gtk_main () from > >>>> /usr/lib64/libgtk-x11-2.0.so.0 > >>>> #19 0x00000000004aa6d4 in main (argc=1, argv=0x7fffffffe438) > >>>> at gui/main.cpp:4562 > >>>> > >>> > >>> What version of libnotify ? > >>> What does grep give as result : > >>> grep closed /usr/include/libnotify/notif* > >>> > >> > >> $ rpm -qa | grep libnotify > >> libnotify-devel-0.4.4-12.fc10.x86_64 > >> libnotify-0.4.4-12.fc10.x86_64 > >> > >> $ grep closed /usr/include/libnotify/notif* > >> /usr/include/libnotify/notification.h: void > >> (*closed)(NotifyNotification *notification, gint reason) > >> > >> which is the problem. Also, gdb reveals that closed_cb() is called > >> with two args, first of which is a *notification pointer, the second > >> a 0x2. > > > > We have the same version (0.4.4), yet the API is different??? Has > > Fedora changed the API??? > > > > Thou Shall Not Guess, once again. Top of the libnotify RPM > changelog'below... > > %changelog > * Sat Aug 23 2008 Matthias Clasen <mcla...@redhat.com> - 0.4.4-12 > - Handle extra parameter of the closed signal > > * Tue Jun 10 2008 Colin Walters <walt...@redhat.com> - 0.4.4-11 > - Add patch neccessary for reliable notification positioning > > * Mon Feb 18 2008 Fedora Release Engineering <rel-...@fedoraproject.org> > - 0.4.4-10 > - Autorebuild for GCC 4.3 >
Which is a problem since the API is differnet in the official and distributed rpms. -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net _______________________________________________ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list