Damien Sandras wrote:
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.
There is something which intrigues me: you have libnotify installed.
configuration step shows: "libnotify disabled". ekiga uses notification
library (because it crashes). How can this be possible?
--
Eugen
_______________________________________________
ekiga-list mailing list
ekiga-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-list
