ekiga for openmoko

[Akiva Torenheim]

Ekiga Dev Community Hello!

I wonder why the lead Open Source VoIp application has no Version for OpenMoko.

Is it in the ToDo list???

--
Akiva Torenheim

akivato@...

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Akiva Torenheim wrote:
> Ekiga Dev Community Hello!
>
> I wonder why the lead Open Source VoIp application has no Version for
> OpenMoko.

Well, there are many platforms around, and ekiga devs do what they can.
  But you can change that: be the first to port ekiga to openmoko!
Could you help?  Compile and analyse the result!

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Luca Capello]

Hi there!

On Sat, 16 May 2009 22:41:40 +0200, Eugen Dedu wrote:
> Akiva Torenheim wrote:
>> Ekiga Dev Community Hello!
>>
>> I wonder why the lead Open Source VoIp application has no Version for
>> OpenMoko.
>
> Well, there are many platforms around, and ekiga devs do what they
> can. But you can change that: be the first to port ekiga to openmoko!
> Could you help?  Compile and analyse the result!

On Debian, Ekiga already compiles fine on both arm (the old ARM ABI) and
armel (the new ARM ABI <http://wiki.debian.org/ArmEabiPort>), thus it
can be easily installed.

OTOH, the last time I tried it (in August 2008 at DebConf8) I was not
able to make/receive any call and since then I just gave up.

Thx, bye,
Gismo / Luca


_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Luca Capello]

Hi there!

On Sun, 17 May 2009 22:36:03 +0200, Luca Capello wrote:
> OTOH, the last time I tried it (in August 2008 at DebConf8) I was not
> able to make/receive any call and since then I just gave up.

I tried again, here the results...


1) Ekiga requires too much disk space:
=====
debian-gta02:~# apt-get install ekiga
[...]
The following NEW packages will be installed:
  ekiga evolution-data-server evolution-data-server-common gvfs
  libbonobo2-0 libbonobo2-common libcamel1.2-14 libcelt0
  libebackend1.2-0 libebook1.2-9 libecal1.2-7 libedata-book1.2-2
  libedata-cal1.2-6 libedataserver1.2-11 libegroupwise1.2-13
  libgdata-google1.2-1 libgdata1.2-1 libgnome2-0 libgnome2-common
  libgweather-common libgweather1 libical0 libltdl7 libnspr4-0d
  libnss3-1d libopal3.6.1 libproxy0 libpt2.6.1 libpt2.6.1-plugins-alsa
  libpt2.6.1-plugins-v4l2 libsoup-gnome2.4-1 libv4l-0 odbcinst1debian1
  unixodbc
0 upgraded, 34 newly installed, 0 to remove and 0 not upgraded.
Need to get 34.8MB of archives.
After this operation, 75.0MB of additional disk space will be used.
[...]

debian-gta02:~# dpkg -s ekiga | grep Version
Version: 3.2.1~git20090515.9d0263-1

debian-gta02:~#
=====

   I would like a minimal version with no GNOME libraries (Bonobo &
   Co.), just Opal, PTlib and the minimum required GTK+, full stop.  May
   I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
   flash?  :-(


2) the wizard is not working properly at 480x640, too much text which
   predates the available space and then you cannot continue because the
   checkboxes are no more visible:

     http://pkg-fso.alioth.debian.org/bugs/ekiga/


3) I can register to ekiga.net and call the echo test at 500@...,
   the echo voice starts instructing me but then ekiga segfault:
=====
debian-gta02:~# DISPLAY=:0.0 gdb ekiga
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabi"...
(gdb) run
Starting program: /usr/bin/ekiga
[Thread debugging using libthread_db enabled]
[New Thread 0x4265f460 (LWP 2467)]
[New Thread 0x4293e410 (LWP 2474)]
[New Thread 0x4297e410 (LWP 2475)]
[New Thread 0x429be410 (LWP 2476)]
[New Thread 0x429fe410 (LWP 2477)]
[New Thread 0x42a3e410 (LWP 2478)]
[New Thread 0x42a7e410 (LWP 2479)]
[New Thread 0x42abe410 (LWP 2480)]
[New Thread 0x42afe410 (LWP 2481)]
[New Thread 0x42b3e410 (LWP 2482)]
[Thread 0x42b3e410 (LWP 2482) exited]
[Thread 0x42abe410 (LWP 2480) exited]
[New Thread 0x42abe410 (LWP 2483)]
[Thread 0x42afe410 (LWP 2481) exited]
[New Thread 0x42afe410 (LWP 2484)]
[New Thread 0x4302b410 (LWP 2485)]
[Thread 0x4302b410 (LWP 2485) exited]
[New Thread 0x4306b410 (LWP 2486)]
[New Thread 0x430ab410 (LWP 2487)]
[Thread 0x4306b410 (LWP 2486) exited]
[New Thread 0x430eb410 (LWP 2488)]
[New Thread 0x4312b410 (LWP 2489)]
[New Thread 0x4316b410 (LWP 2490)]
[New Thread 0x431ab410 (LWP 2491)]
[New Thread 0x431eb410 (LWP 2492)]
[New Thread 0x4322b410 (LWP 2493)]

(ekiga:2467): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
The program 'ekiga' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 34 error_code 8 request_code 139 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
[New Thread 0x4339e410 (LWP 2494)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x429be410 (LWP 2476)]
0x40ffd7d0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
(gdb) bt
#0  0x40ffd7d0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
Cannot access memory at address 0x1
(gdb) quit
The program is running.  Exit anyway? (y or n) y
debian-gta02:~#
=====

It is better than August 2008, but not yet perfect ;-)

Thx, bye,
Gismo / Luca


_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Luca Capello a écrit :

> Hi there!
>
> On Sun, 17 May 2009 22:36:03 +0200, Luca Capello wrote:
>> OTOH, the last time I tried it (in August 2008 at DebConf8) I was not
>> able to make/receive any call and since then I just gave up.
>
> I tried again, here the results...
>
>
> 1) Ekiga requires too much disk space:
> =====
> debian-gta02:~# apt-get install ekiga
> [...]
> The following NEW packages will be installed:
>   ekiga evolution-data-server evolution-data-server-common gvfs
>   libbonobo2-0 libbonobo2-common libcamel1.2-14 libcelt0
>   libebackend1.2-0 libebook1.2-9 libecal1.2-7 libedata-book1.2-2
>   libedata-cal1.2-6 libedataserver1.2-11 libegroupwise1.2-13
>   libgdata-google1.2-1 libgdata1.2-1 libgnome2-0 libgnome2-common
>   libgweather-common libgweather1 libical0 libltdl7 libnspr4-0d
>   libnss3-1d libopal3.6.1 libproxy0 libpt2.6.1 libpt2.6.1-plugins-alsa
>   libpt2.6.1-plugins-v4l2 libsoup-gnome2.4-1 libv4l-0 odbcinst1debian1
>   unixodbc
> 0 upgraded, 34 newly installed, 0 to remove and 0 not upgraded.
> Need to get 34.8MB of archives.
> After this operation, 75.0MB of additional disk space will be used.
> [...]
>
> debian-gta02:~# dpkg -s ekiga | grep Version
> Version: 3.2.1~git20090515.9d0263-1
>
> debian-gta02:~#
> =====
>
>    I would like a minimal version with no GNOME libraries (Bonobo &
>    Co.), just Opal, PTlib and the minimum required GTK+, full stop.  May
>    I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
>    flash?  :-(

It *is* possible to disable the evolution support -- it looks like it's
the culprit behind most of the deps.

> 3) I can register to ekiga.net and call the echo test at 500@...,
>    the echo voice starts instructing me but then ekiga segfault:
> =====
> debian-gta02:~# DISPLAY=:0.0 gdb ekiga
> GNU gdb 6.8-debian
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-linux-gnueabi"...

> (ekiga:2467): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
> The program 'ekiga' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadMatch (invalid parameter attributes)'.
>   (Details: serial 34 error_code 8 request_code 139 minor_code 3)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() function.)
> [New Thread 0x4339e410 (LWP 2494)]

It looks like a threading issue, but I can't tell more.

> It is better than August 2008, but not yet perfect ;-)

It would be interesting to get it going. Is there an easy way for a
debian user to install a good ARM virtual machine on a ix86 computer?
[and to cross-compile ekiga for testing?]

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Luca Capello]

Hi Julien!

On Sun, 07 Jun 2009 18:40:43 +0200, Julien Puydt wrote:
> Luca Capello a écrit :
>> 1) Ekiga requires too much disk space:
[...]
>>    I would like a minimal version with no GNOME libraries (Bonobo &
>>    Co.), just Opal, PTlib and the minimum required GTK+, full stop.  May
>>    I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
>>    flash?  :-(
>
> It *is* possible to disable the evolution support -- it looks like
> it's the culprit behind most of the deps.

Eugen, should I officially ask for a ekiga-gtk-only package?

>> 3) I can register to ekiga.net and call the echo test at 500@...,
>>    the echo voice starts instructing me but then ekiga segfault:
[...]
>> [New Thread 0x4339e410 (LWP 2494)]
>
> It looks like a threading issue, but I can't tell more.
>
>> It is better than August 2008, but not yet perfect ;-)
>
> It would be interesting to get it going. Is there an easy way for a
> debian user to install a good ARM virtual machine on a ix86 computer?
> [and to cross-compile ekiga for testing?]

You can use the stock QEMU in Debian as explained at:

  http://wiki.debian.org/DebianOnFreeRunner#DevelopApplicationsforandonDebian

Then you do not cross-compile, but instead you build Debian packages on
that QEMU image.  However, I have never tried to run X.Org on such an
image (and nowadays I do everything on a real ARM machine, my Openmoko
GTA01 and GTA02).

Thx, bye,
Gismo / Luca


_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Luca Capello]

Hi there!

On Sun, 07 Jun 2009 17:59:11 +0200, Luca Capello wrote:
> debian-gta02:~# DISPLAY=:0.0 gdb ekiga
[...]

> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x429be410 (LWP 2476)]
> 0x40ffd7d0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> (gdb) bt
> #0  0x40ffd7d0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> Cannot access memory at address 0x1
> (gdb) quit
> The program is running.  Exit anyway? (y or n) y
> debian-gta02:~#
> =====

If it can be useful, I tried again after having installed
libgtk2.0-0-dbg and libglib2.0-0-dbg:
=====
debian-gta02:~# DISPLAY=:0.0 gdb ekiga
[...]
(gdb) run
Starting program: /usr/bin/ekiga
[Thread debugging using libthread_db enabled]
[New Thread 0x4265f460 (LWP 1855)]
[New Thread 0x4293e410 (LWP 1865)]
[New Thread 0x4297e410 (LWP 1866)]
[New Thread 0x429be410 (LWP 1867)]
[New Thread 0x429fe410 (LWP 1868)]
[New Thread 0x42a3e410 (LWP 1869)]
[New Thread 0x42a7e410 (LWP 1870)]
[New Thread 0x42abe410 (LWP 1871)]
[New Thread 0x42afe410 (LWP 1872)]
[New Thread 0x42b3e410 (LWP 1873)]
[Thread 0x42b3e410 (LWP 1873) exited]
[Thread 0x42abe410 (LWP 1871) exited]
[New Thread 0x42abe410 (LWP 1876)]
[Thread 0x42afe410 (LWP 1872) exited]
[New Thread 0x42afe410 (LWP 1877)]
[New Thread 0x42f0c410 (LWP 1878)]
[Thread 0x42f0c410 (LWP 1878) exited]
[New Thread 0x42f4c410 (LWP 1885)]
[New Thread 0x42f8c410 (LWP 1886)]
[New Thread 0x42fcc410 (LWP 1888)]
[New Thread 0x4323f410 (LWP 1889)]
[Thread 0x42f4c410 (LWP 1885) exited]
[New Thread 0x4327f410 (LWP 1891)]
[New Thread 0x432bf410 (LWP 1892)]
[New Thread 0x432ff410 (LWP 1893)]
[New Thread 0x4333f410 (LWP 1894)]
[New Thread 0x43414410 (LWP 1895)]

(ekiga:1855): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
The program 'ekiga' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 34 error_code 8 request_code 139 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
      assert.cxx(108)   PWLib   Assertion fail: Function pthread_mutex_lock failed, file ptlib/unix/tlibthrd.cxx, line 1320
Assertion fail: Function pthread_mutex_lock failed, file ptlib/unix/tlibthrd.cxx, line 1320

<A>bort, <C>ore dump? c[New Thread 0x434d9410 (LWP 1907)]
GConf Error: Failed to contact configuration server; some possible causes are that you need
 to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash.
 See http://projects.gnome.org/gconf/ for information. (Details -  1: Could not send message
 to gconf daemon: Did not receive a reply. Possible causes include: the remote application
 did not send a reply, the message bus security policy blocked the reply, the reply timeout
 expired, or the network connection was broken.)
GConf Error: Failed to contact configuration server; some possible causes are that you need
 to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash.
 See http://projects.gnome.org/gconf/ for information. (Details -  1: Could not send message
 to gconf daemon: Did not receive a reply. Possible causes include: the remote application
 did not send a reply, the message bus security policy blocked the reply, the reply timeout
 expired, or the network connection was broken.)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x4265f460 (LWP 1855)]
get_btree (buffer=0x0) at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextbuffer.c:789
789     /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextbuffer.c: No such file or directory.
        in /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextbuffer.c
Current language:  auto; currently c
(gdb) thread
[Current thread is 1 (Thread 0x4265f460 (LWP 1855))]
(gdb) bt
#0  get_btree (buffer=0x0) at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextbuffer.c:789
#1  0x4101efb8 in IA__gtk_text_layout_validate_yrange (layout=0x43dad8, anchor=0x411dd928,
    y0=<value optimized out>, y1=2256960)
    at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextlayout.c:1062
#2  0x4102b908 in gtk_text_view_validate_onscreen (text_view=0x40b110)
    at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextview.c:3502
#3  0x4102d0dc in gtk_text_view_flush_first_validate (text_view=0x40b110)
    at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextview.c:3558
#4  0x4102d138 in first_validate_callback (data=0x0)
    at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextview.c:3577
#5  0x41217b60 in gdk_threads_dispatch (data=0x450720)
    at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gdk/gdk.c:498
#6  0x413a9bac in g_idle_dispatch (source=<value optimized out>, callback=0x41217ae8 <gdk_threads_dispatch>,
    user_data=0x0) at /build/buildd-glib2.0_2.20.3-1-armel-HORSLJ/glib2.0-2.20.3/glib/gmain.c:3919
#7  0x413abd64 in IA__g_main_context_dispatch (context=0x450720)
    at /build/buildd-glib2.0_2.20.3-1-armel-HORSLJ/glib2.0-2.20.3/glib/gmain.c:1814
#8  0x413af670 in g_main_context_iterate (context=0x243d68, block=2455240, dispatch=1086773184,
    self=<value optimized out>) at /build/buildd-glib2.0_2.20.3-1-armel-HORSLJ/glib2.0-2.20.3/glib/gmain.c:2445
#9  0x413afb8c in IA__g_main_loop_run (loop=0x505898)
    at /build/buildd-glib2.0_2.20.3-1-armel-HORSLJ/glib2.0-2.20.3/glib/gmain.c:2653
#10 0x40f6afd4 in IA__gtk_main ()
    at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtkmain.c:1205
#11 0x000a1c0c in main (argc=0, argv=0x64) at gui/main.cpp:4571
(gdb)
=====

Actually, I also got another unrelated segfault:
=====
debian-gta02:~# DISPLAY=:0.0 gdb ekiga
[...]
(gdb) run
Starting program: /usr/bin/ekiga
[Thread debugging using libthread_db enabled]
[New Thread 0x4265f460 (LWP 1775)]
[New Thread 0x4293e410 (LWP 1785)]
[New Thread 0x4297e410 (LWP 1786)]
[New Thread 0x429be410 (LWP 1787)]
[New Thread 0x429fe410 (LWP 1788)]
[New Thread 0x42a3e410 (LWP 1789)]
[New Thread 0x42a7e410 (LWP 1790)]
[New Thread 0x42abe410 (LWP 1791)]
[New Thread 0x42afe410 (LWP 1792)]
[New Thread 0x42b3e410 (LWP 1793)]
[Thread 0x42b3e410 (LWP 1793) exited]
[Thread 0x42abe410 (LWP 1791) exited]
[New Thread 0x42abe410 (LWP 1796)]
[Thread 0x42afe410 (LWP 1792) exited]
[New Thread 0x42afe410 (LWP 1797)]
[New Thread 0x42f0c410 (LWP 1798)]
[Thread 0x42f0c410 (LWP 1798) exited]
[New Thread 0x42f4c410 (LWP 1803)]
[New Thread 0x42f8c410 (LWP 1805)]
[New Thread 0x42fcc410 (LWP 1806)]
[New Thread 0x4313f410 (LWP 1807)]
[Thread 0x42f4c410 (LWP 1803) exited]
[New Thread 0x4317f410 (LWP 1809)]
[New Thread 0x431bf410 (LWP 1810)]
[New Thread 0x431ff410 (LWP 1811)]
[New Thread 0x4323f410 (LWP 1812)]
[New Thread 0x43314410 (LWP 1813)]

(ekiga:1775): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
The program 'ekiga' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 34 error_code 8 request_code 139 minor_code 3)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
      assert.cxx(108)   PWLib   Assertion fail: Function pthread_mutex_lock failed, file ptlib/unix/tlibthrd.cxx, line 1320, Error=107
Assertion fail: Function pthread_mutex_lock failed, file ptlib/unix/tlibthrd.cxx, line 1320, Error=107

<A>bort, <C>ore dump? c

Dumping core.

Ignoring.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x42abe410 (LWP 1796)]
0x00000000 in ?? ()
(gdb) thread
[Current thread is 11 (Thread 0x42abe410 (LWP 1796))]
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x40beef50 in PHostByName::GetHost () from /usr/lib/libpt.so.2.6.1
#2  0x40bef308 in PHostByName::GetHostAddress () from /usr/lib/libpt.so.2.6.1
#3  0x40bef420 in PIPSocket::GetHostAddress () from /usr/lib/libpt.so.2.6.1
#4  0x4045eb70 in OpalInternalIPTransport::GetIpAndPort () from /usr/lib/libopal.so.3.6.1
#5  0x4045b368 in OpalTransportAddress::GetIpAddress () from /usr/lib/libopal.so.3.6.1
#6  0x40461cf8 in OpalListenerUDP::CreateTransport () from /usr/lib/libopal.so.3.6.1
#7  0x4083fa24 in SIPEndPoint::CreateTransport () from /usr/lib/libopal.so.3.6.1
#8  0x408856f4 in SIPHandler::GetTransport () from /usr/lib/libopal.so.3.6.1
#9  0x408814b4 in SIPHandler::SendRequest () from /usr/lib/libopal.so.3.6.1
#10 0x4083d748 in SIPEndPoint::Subscribe () from /usr/lib/libopal.so.3.6.1
#11 0x4088521c in SIPSubscribeHandler::OnFailed () from /usr/lib/libopal.so.3.6.1
#12 0x4083c938 in SIPEndPoint::OnReceivedResponse () from /usr/lib/libopal.so.3.6.1
#13 0x4085e0ac in SIPTransaction::OnReceivedResponse () from /usr/lib/libopal.so.3.6.1
#14 0x4083cfdc in SIPEndPoint::OnReceivedConnectionlessPDU () from /usr/lib/libopal.so.3.6.1
#15 0x4083e5e0 in SIPEndPoint::OnReceivedPDU () from /usr/lib/libopal.so.3.6.1
#16 0x40841f34 in SIPEndPoint::HandlePDU () from /usr/lib/libopal.so.3.6.1
#17 0x4083f83c in SIPEndPoint::NewIncomingConnection () from /usr/lib/libopal.so.3.6.1
#18 0x4041fbd4 in OpalEndPoint::ListenerCallback () from /usr/lib/libopal.so.3.6.1
#19 0x40422ebc in OpalEndPoint::ListenerCallback_PNotifier::Call () from /usr/lib/libopal.so.3.6.1
warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)

#20 0x00161324 in PNotifier::operator() (this=warning: (Internal error: pc 0x1612e4 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)

0x2bd304, notifier=@0x2bd2f8, extra=2879024)
    at /usr/include/ptlib/notifier.h:125
#21 0x4046304c in OpalListener::ListenForConnections () from /usr/lib/libopal.so.3.6.1
#22 0x4046518c in OpalListener::ListenForConnections_PNotifier::Call () from /usr/lib/libopal.so.3.6.1
warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)

#23 0x00161324 in PNotifier::operator() (this=warning: (Internal error: pc 0x1612e4 in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)

0x29c8dc, notifier=@0x29c858, extra=0)
    at /usr/include/ptlib/notifier.h:125
#24 0x40bfbd38 in PSimpleThread::Main () from /usr/lib/libpt.so.2.6.1
#25 0x40bce48c in PThread::PX_ThreadStart () from /usr/lib/libpt.so.2.6.1
#26 0x40c6c2d4 in start_thread () from /lib/libpthread.so.0
#27 0x416b31a8 in clone () from /lib/libc.so.6
Backtrace stopped: frame did not save the PC
(gdb)
=====

Thx, bye,
Gismo / Luca


_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Luca Capello a écrit :
> (ekiga:1855): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
> The program 'ekiga' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadMatch (invalid parameter attributes)'.

Let me guess : you don't have accelerated hardware... and hence rely on
the X code instead of the XV code...

Sigh... if only Matthias could help there :-(

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Luca Capello wrote:

> Hi there!
>
> On Sun, 07 Jun 2009 17:59:11 +0200, Luca Capello wrote:
>> debian-gta02:~# DISPLAY=:0.0 gdb ekiga
> [...]
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x429be410 (LWP 2476)]
>> 0x40ffd7d0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
>> (gdb) bt
>> #0  0x40ffd7d0 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
>> Cannot access memory at address 0x1
>> (gdb) quit
>> The program is running.  Exit anyway? (y or n) y
>> debian-gta02:~#
>> =====
>
> If it can be useful, I tried again after having installed
> libgtk2.0-0-dbg and libglib2.0-0-dbg:
> =====
> debian-gta02:~# DISPLAY=:0.0 gdb ekiga
> [...]
> (gdb) run
> Starting program: /usr/bin/ekiga
> [Thread debugging using libthread_db enabled]
> [New Thread 0x4265f460 (LWP 1855)]
> [New Thread 0x4293e410 (LWP 1865)]
> [New Thread 0x4297e410 (LWP 1866)]
> [New Thread 0x429be410 (LWP 1867)]
> [New Thread 0x429fe410 (LWP 1868)]
> [New Thread 0x42a3e410 (LWP 1869)]
> [New Thread 0x42a7e410 (LWP 1870)]
> [New Thread 0x42abe410 (LWP 1871)]
> [New Thread 0x42afe410 (LWP 1872)]
> [New Thread 0x42b3e410 (LWP 1873)]
> [Thread 0x42b3e410 (LWP 1873) exited]
> [Thread 0x42abe410 (LWP 1871) exited]
> [New Thread 0x42abe410 (LWP 1876)]
> [Thread 0x42afe410 (LWP 1872) exited]
> [New Thread 0x42afe410 (LWP 1877)]
> [New Thread 0x42f0c410 (LWP 1878)]
> [Thread 0x42f0c410 (LWP 1878) exited]
> [New Thread 0x42f4c410 (LWP 1885)]
> [New Thread 0x42f8c410 (LWP 1886)]
> [New Thread 0x42fcc410 (LWP 1888)]
> [New Thread 0x4323f410 (LWP 1889)]
> [Thread 0x42f4c410 (LWP 1885) exited]
> [New Thread 0x4327f410 (LWP 1891)]
> [New Thread 0x432bf410 (LWP 1892)]
> [New Thread 0x432ff410 (LWP 1893)]
> [New Thread 0x4333f410 (LWP 1894)]
> [New Thread 0x43414410 (LWP 1895)]
>
> (ekiga:1855): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
> The program 'ekiga' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadMatch (invalid parameter attributes)'.
>   (Details: serial 34 error_code 8 request_code 139 minor_code 3)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() function.)
>       assert.cxx(108)   PWLib   Assertion fail: Function pthread_mutex_lock failed, file ptlib/unix/tlibthrd.cxx, line 1320
> Assertion fail: Function pthread_mutex_lock failed, file ptlib/unix/tlibthrd.cxx, line 1320
>
> <A>bort, <C>ore dump? c[New Thread 0x434d9410 (LWP 1907)]
> GConf Error: Failed to contact configuration server; some possible causes are that you need
>  to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash.
>  See http://projects.gnome.org/gconf/ for information. (Details -  1: Could not send message
>  to gconf daemon: Did not receive a reply. Possible causes include: the remote application
>  did not send a reply, the message bus security policy blocked the reply, the reply timeout
>  expired, or the network connection was broken.)
> GConf Error: Failed to contact configuration server; some possible causes are that you need
>  to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash.
>  See http://projects.gnome.org/gconf/ for information. (Details -  1: Could not send message
>  to gconf daemon: Did not receive a reply. Possible causes include: the remote application
>  did not send a reply, the message bus security policy blocked the reply, the reply timeout
>  expired, or the network connection was broken.)
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x4265f460 (LWP 1855)]
> get_btree (buffer=0x0) at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextbuffer.c:789
> 789     /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextbuffer.c: No such file or directory.
>         in /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextbuffer.c
> Current language:  auto; currently c
> (gdb) thread
> [Current thread is 1 (Thread 0x4265f460 (LWP 1855))]
> (gdb) bt

Hi,

To my knowledge, it's better to use thread apply all bt, is that right?

On the other hand, I have this crash too sometimes
(ptlib/unix/tlibthrd.cxx assertion), I will reproduce it and send it to
Robert to analyse it; hopefuly it will be fixed soon.

> #0  get_btree (buffer=0x0) at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextbuffer.c:789
> #1  0x4101efb8 in IA__gtk_text_layout_validate_yrange (layout=0x43dad8, anchor=0x411dd928,
>     y0=<value optimized out>, y1=2256960)
>     at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextlayout.c:1062
> #2  0x4102b908 in gtk_text_view_validate_onscreen (text_view=0x40b110)
>     at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextview.c:3502
> #3  0x4102d0dc in gtk_text_view_flush_first_validate (text_view=0x40b110)
>     at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextview.c:3558
> #4  0x4102d138 in first_validate_callback (data=0x0)
>     at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtktextview.c:3577
> #5  0x41217b60 in gdk_threads_dispatch (data=0x450720)
>     at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gdk/gdk.c:498
> #6  0x413a9bac in g_idle_dispatch (source=<value optimized out>, callback=0x41217ae8 <gdk_threads_dispatch>,
>     user_data=0x0) at /build/buildd-glib2.0_2.20.3-1-armel-HORSLJ/glib2.0-2.20.3/glib/gmain.c:3919
> #7  0x413abd64 in IA__g_main_context_dispatch (context=0x450720)
>     at /build/buildd-glib2.0_2.20.3-1-armel-HORSLJ/glib2.0-2.20.3/glib/gmain.c:1814
> #8  0x413af670 in g_main_context_iterate (context=0x243d68, block=2455240, dispatch=1086773184,
>     self=<value optimized out>) at /build/buildd-glib2.0_2.20.3-1-armel-HORSLJ/glib2.0-2.20.3/glib/gmain.c:2445
> #9  0x413afb8c in IA__g_main_loop_run (loop=0x505898)
>     at /build/buildd-glib2.0_2.20.3-1-armel-HORSLJ/glib2.0-2.20.3/glib/gmain.c:2653
> #10 0x40f6afd4 in IA__gtk_main ()
>     at /build/buildd-gtk+2.0_2.16.2-1-armel-zsOykG/gtk+2.0-2.16.2/gtk/gtkmain.c:1205
> #11 0x000a1c0c in main (argc=0, argv=0x64) at gui/main.cpp:4571
> (gdb)
> =====
>
> Actually, I also got another unrelated segfault:
> =====
> debian-gta02:~# DISPLAY=:0.0 gdb ekiga
> [...]
> (gdb) run
> Starting program: /usr/bin/ekiga
> [Thread debugging using libthread_db enabled]
> [New Thread 0x4265f460 (LWP 1775)]
> [New Thread 0x4293e410 (LWP 1785)]
> [New Thread 0x4297e410 (LWP 1786)]
> [New Thread 0x429be410 (LWP 1787)]
> [New Thread 0x429fe410 (LWP 1788)]
> [New Thread 0x42a3e410 (LWP 1789)]
> [New Thread 0x42a7e410 (LWP 1790)]
> [New Thread 0x42abe410 (LWP 1791)]
> [New Thread 0x42afe410 (LWP 1792)]
> [New Thread 0x42b3e410 (LWP 1793)]
> [Thread 0x42b3e410 (LWP 1793) exited]
> [Thread 0x42abe410 (LWP 1791) exited]
> [New Thread 0x42abe410 (LWP 1796)]
> [Thread 0x42afe410 (LWP 1792) exited]
> [New Thread 0x42afe410 (LWP 1797)]
> [New Thread 0x42f0c410 (LWP 1798)]
> [Thread 0x42f0c410 (LWP 1798) exited]
> [New Thread 0x42f4c410 (LWP 1803)]
> [New Thread 0x42f8c410 (LWP 1805)]
> [New Thread 0x42fcc410 (LWP 1806)]
> [New Thread 0x4313f410 (LWP 1807)]
> [Thread 0x42f4c410 (LWP 1803) exited]
> [New Thread 0x4317f410 (LWP 1809)]
> [New Thread 0x431bf410 (LWP 1810)]
> [New Thread 0x431ff410 (LWP 1811)]
> [New Thread 0x4323f410 (LWP 1812)]
> [New Thread 0x43314410 (LWP 1813)]
>
> (ekiga:1775): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display: assertion `atom != GDK_NONE' failed
> The program 'ekiga' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadMatch (invalid parameter attributes)'.
>   (Details: serial 34 error_code 8 request_code 139 minor_code 3)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error() function.)
>       assert.cxx(108)   PWLib   Assertion fail: Function pthread_mutex_lock failed, file ptlib/unix/tlibthrd.cxx, line 1320, Error=107
> Assertion fail: Function pthread_mutex_lock failed, file ptlib/unix/tlibthrd.cxx, line 1320, Error=107
>
> <A>bort, <C>ore dump? c
>
> Dumping core.
>
> Ignoring.
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x42abe410 (LWP 1796)]
> 0x00000000 in ?? ()
> (gdb) thread
> [Current thread is 11 (Thread 0x42abe410 (LWP 1796))]
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0x40beef50 in PHostByName::GetHost () from /usr/lib/libpt.so.2.6.1
> #2  0x40bef308 in PHostByName::GetHostAddress () from /usr/lib/libpt.so.2.6.1
> #3  0x40bef420 in PIPSocket::GetHostAddress () from /usr/lib/libpt.so.2.6.1
> #4  0x4045eb70 in OpalInternalIPTransport::GetIpAndPort () from /usr/lib/libopal.so.3.6.1
> #5  0x4045b368 in OpalTransportAddress::GetIpAddress () from /usr/lib/libopal.so.3.6.1
> #6  0x40461cf8 in OpalListenerUDP::CreateTransport () from /usr/lib/libopal.so.3.6.1
> #7  0x4083fa24 in SIPEndPoint::CreateTransport () from /usr/lib/libopal.so.3.6.1
> #8  0x408856f4 in SIPHandler::GetTransport () from /usr/lib/libopal.so.3.6.1
> #9  0x408814b4 in SIPHandler::SendRequest () from /usr/lib/libopal.so.3.6.1
> #10 0x4083d748 in SIPEndPoint::Subscribe () from /usr/lib/libopal.so.3.6.1
> #11 0x4088521c in SIPSubscribeHandler::OnFailed () from /usr/lib/libopal.so.3.6.1
> #12 0x4083c938 in SIPEndPoint::OnReceivedResponse () from /usr/lib/libopal.so.3.6.1
> #13 0x4085e0ac in SIPTransaction::OnReceivedResponse () from /usr/lib/libopal.so.3.6.1
> #14 0x4083cfdc in SIPEndPoint::OnReceivedConnectionlessPDU () from /usr/lib/libopal.so.3.6.1
> #15 0x4083e5e0 in SIPEndPoint::OnReceivedPDU () from /usr/lib/libopal.so.3.6.1
> #16 0x40841f34 in SIPEndPoint::HandlePDU () from /usr/lib/libopal.so.3.6.1
> #17 0x4083f83c in SIPEndPoint::NewIncomingConnection () from /usr/lib/libopal.so.3.6.1
> #18 0x4041fbd4 in OpalEndPoint::ListenerCallback () from /usr/lib/libopal.so.3.6.1
> #19 0x40422ebc in OpalEndPoint::ListenerCallback_PNotifier::Call () from /usr/lib/libopal.so.3.6.1
> warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)
>
> #20 0x00161324 in PNotifier::operator() (this=warning: (Internal error: pc 0x1612e4 in read in psymtab, but not in symtab.)
>
> warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)
>
> 0x2bd304, notifier=@0x2bd2f8, extra=2879024)
>     at /usr/include/ptlib/notifier.h:125
> #21 0x4046304c in OpalListener::ListenForConnections () from /usr/lib/libopal.so.3.6.1
> #22 0x4046518c in OpalListener::ListenForConnections_PNotifier::Call () from /usr/lib/libopal.so.3.6.1
> warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)
>
> warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)
>
> #23 0x00161324 in PNotifier::operator() (this=warning: (Internal error: pc 0x1612e4 in read in psymtab, but not in symtab.)
>
> warning: (Internal error: pc 0x161323 in read in psymtab, but not in symtab.)
>
> 0x29c8dc, notifier=@0x29c858, extra=0)
>     at /usr/include/ptlib/notifier.h:125
> #24 0x40bfbd38 in PSimpleThread::Main () from /usr/lib/libpt.so.2.6.1
> #25 0x40bce48c in PThread::PX_ThreadStart () from /usr/lib/libpt.so.2.6.1
> #26 0x40c6c2d4 in start_thread () from /lib/libpthread.so.0
> #27 0x416b31a8 in clone () from /lib/libc.so.6
> Backtrace stopped: frame did not save the PC
> (gdb)
> =====

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Julien Puydt wrote:
> Luca Capello a écrit :
>> (ekiga:1855): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display:
>> assertion `atom != GDK_NONE' failed

This is an error I have started to have since about one week.  I think
it's an X library which checks that.  Other programs. like iceweasel
(firefox) have it too.

>> The program 'ekiga' received an X Window System error.
>> This probably reflects a bug in the program.
>> The error was 'BadMatch (invalid parameter attributes)'.
>
> Let me guess : you don't have accelerated hardware... and hence rely on
> the X code instead of the XV code...

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Luca Capello wrote:

> Hi there!
>
> On Sun, 17 May 2009 22:36:03 +0200, Luca Capello wrote:
>> OTOH, the last time I tried it (in August 2008 at DebConf8) I was not
>> able to make/receive any call and since then I just gave up.
>
> 2) the wizard is not working properly at 480x640, too much text which
>    predates the available space and then you cannot continue because the
>    checkboxes are no more visible:
>
>      http://pkg-fso.alioth.debian.org/bugs/ekiga/

This is a known issue http://bugzilla.gnome.org/show_bug.cgi?id=552870,
which is not yet fixed, please wait...  For info, there is also a new
assistant proposal http://bugzilla.gnome.org/show_bug.cgi?id=540301,
let's wait a bit to find the best solution for this.

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Luca Capello wrote:

> Hi Julien!
>
> On Sun, 07 Jun 2009 18:40:43 +0200, Julien Puydt wrote:
>> Luca Capello a écrit :
>>> 1) Ekiga requires too much disk space:
> [...]
>>>    I would like a minimal version with no GNOME libraries (Bonobo &
>>>    Co.), just Opal, PTlib and the minimum required GTK+, full stop.  May
>>>    I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
>>>    flash?  :-(
>> It *is* possible to disable the evolution support -- it looks like
>> it's the culprit behind most of the deps.
>
> Eugen, should I officially ask for a ekiga-gtk-only package?

A similar report exists on debian bugzilla,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520830 .  The best
solution is to add runtime detection (used by those who installed it,
not used by the others), as shown here:

"what you suggest ("ekiga: Dependancy on evolution-data-server should be
removed or moved to additional package") should be possible after adding
runtime detection of evolution-data-server to Ekiga."

Could that be done in ekiga?

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Eugen Dedu a écrit :

> Luca Capello wrote:
>> Hi Julien!
>>
>> On Sun, 07 Jun 2009 18:40:43 +0200, Julien Puydt wrote:
>>> Luca Capello a écrit :
>>>> 1) Ekiga requires too much disk space:
>> [...]
>>>>    I would like a minimal version with no GNOME libraries (Bonobo &
>>>>    Co.), just Opal, PTlib and the minimum required GTK+, full stop.  
>>>> May
>>>>    I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
>>>>    flash?  :-(
>>> It *is* possible to disable the evolution support -- it looks like
>>> it's the culprit behind most of the deps.
>>
>> Eugen, should I officially ask for a ekiga-gtk-only package?
>
> A similar report exists on debian bugzilla,
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520830 .  The best
> solution is to add runtime detection (used by those who installed it,
> not used by the others), as shown here:
>
> "what you suggest ("ekiga: Dependancy on evolution-data-server should be
> removed or moved to additional package") should be possible after adding
> runtime detection of evolution-data-server to Ekiga."
>
> Could that be done in ekiga?
>

Make the evolution code a plugin... the basic framework is here... we
even already have a plugin loader!

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Julien Puydt wrote:

> Eugen Dedu a écrit :
>> Luca Capello wrote:
>>> Hi Julien!
>>>
>>> On Sun, 07 Jun 2009 18:40:43 +0200, Julien Puydt wrote:
>>>> Luca Capello a écrit :
>>>>> 1) Ekiga requires too much disk space:
>>> [...]
>>>>>    I would like a minimal version with no GNOME libraries (Bonobo &
>>>>>    Co.), just Opal, PTlib and the minimum required GTK+, full
>>>>> stop.  May
>>>>>    I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
>>>>>    flash?  :-(
>>>> It *is* possible to disable the evolution support -- it looks like
>>>> it's the culprit behind most of the deps.
>>>
>>> Eugen, should I officially ask for a ekiga-gtk-only package?
>>
>> A similar report exists on debian bugzilla,
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520830 .  The best
>> solution is to add runtime detection (used by those who installed it,
>> not used by the others), as shown here:
>>
>> "what you suggest ("ekiga: Dependancy on evolution-data-server should be
>> removed or moved to additional package") should be possible after adding
>> runtime detection of evolution-data-server to Ekiga."
>>
>> Could that be done in ekiga?
>>
> Make the evolution code a plugin... the basic framework is here... we
> even already have a plugin loader!

I made a bug report, not to forget it:
http://bugzilla.gnome.org/show_bug.cgi?id=586147

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Eugen Dedu wrote:

> Julien Puydt wrote:
>> Eugen Dedu a écrit :
>>> Luca Capello wrote:
>>>> Hi Julien!
>>>>
>>>> On Sun, 07 Jun 2009 18:40:43 +0200, Julien Puydt wrote:
>>>>> Luca Capello a écrit :
>>>>>> 1) Ekiga requires too much disk space:
>>>> [...]
>>>>>>    I would like a minimal version with no GNOME libraries (Bonobo &
>>>>>>    Co.), just Opal, PTlib and the minimum required GTK+, full
>>>>>> stop.  May
>>>>>>    I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
>>>>>>    flash?  :-(
>>>>> It *is* possible to disable the evolution support -- it looks like
>>>>> it's the culprit behind most of the deps.
>>>>
>>>> Eugen, should I officially ask for a ekiga-gtk-only package?
>>>
>>> A similar report exists on debian bugzilla,
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520830 .  The best
>>> solution is to add runtime detection (used by those who installed it,
>>> not used by the others), as shown here:
>>>
>>> "what you suggest ("ekiga: Dependancy on evolution-data-server should be
>>> removed or moved to additional package") should be possible after adding
>>> runtime detection of evolution-data-server to Ekiga."
>>>
>>> Could that be done in ekiga?
>>>
>> Make the evolution code a plugin... the basic framework is here... we
>> even already have a plugin loader!
>
> I made a bug report, not to forget it:
> http://bugzilla.gnome.org/show_bug.cgi?id=586147

Julien has just fixed it on master: evolution (and kde, kab etc.) are
plugins now.  Julien, could you explain how this affects building (if it
does affect)?  Are these plugins generated as .so or what?  Are they
always built or what?

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

Eugen Dedu a écrit :

> Eugen Dedu wrote:
>> Julien Puydt wrote:
>>> Eugen Dedu a écrit :
>>>> Luca Capello wrote:
>>>>> Hi Julien!
>>>>>
>>>>> On Sun, 07 Jun 2009 18:40:43 +0200, Julien Puydt wrote:
>>>>>> Luca Capello a écrit :
>>>>>>> 1) Ekiga requires too much disk space:
>>>>> [...]
>>>>>>>    I would like a minimal version with no GNOME libraries (Bonobo &
>>>>>>>    Co.), just Opal, PTlib and the minimum required GTK+, full
>>>>>>> stop.  May
>>>>>>>    I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
>>>>>>>    flash?  :-(
>>>>>> It *is* possible to disable the evolution support -- it looks like
>>>>>> it's the culprit behind most of the deps.
>>>>>
>>>>> Eugen, should I officially ask for a ekiga-gtk-only package?
>>>>
>>>> A similar report exists on debian bugzilla,
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520830 .  The best
>>>> solution is to add runtime detection (used by those who installed
>>>> it, not used by the others), as shown here:
>>>>
>>>> "what you suggest ("ekiga: Dependancy on evolution-data-server
>>>> should be
>>>> removed or moved to additional package") should be possible after
>>>> adding
>>>> runtime detection of evolution-data-server to Ekiga."
>>>>
>>>> Could that be done in ekiga?
>>>>
>>> Make the evolution code a plugin... the basic framework is here... we
>>> even already have a plugin loader!
>>
>> I made a bug report, not to forget it:
>> http://bugzilla.gnome.org/show_bug.cgi?id=586147
>
> Julien has just fixed it on master: evolution (and kde, kab etc.) are
> plugins now.  Julien, could you explain how this affects building (if it
> does affect)?  Are these plugins generated as .so or what?  Are they
> always built or what?

Well, it's still possible not to build those pieces of code with the
usual --disable switches : that didn't change.

The difference is that now, when it's built, it's possible to package
ekiga and those pieces separately ; the ekiga executable doesn't have
those features (and doesn't link to the libs they depend on).

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

Julien Puydt wrote:

> Eugen Dedu a écrit :
>> Eugen Dedu wrote:
>>> Julien Puydt wrote:
>>>> Eugen Dedu a écrit :
>>>>> Luca Capello wrote:
>>>>>> Hi Julien!
>>>>>>
>>>>>> On Sun, 07 Jun 2009 18:40:43 +0200, Julien Puydt wrote:
>>>>>>> Luca Capello a écrit :
>>>>>>>> 1) Ekiga requires too much disk space:
>>>>>> [...]
>>>>>>>>    I would like a minimal version with no GNOME libraries (Bonobo &
>>>>>>>>    Co.), just Opal, PTlib and the minimum required GTK+, full
>>>>>>>> stop.  May
>>>>>>>>    I remind you that the Openmoko GTA02 Neo FreeRunner has 256MB of
>>>>>>>>    flash?  :-(
>>>>>>> It *is* possible to disable the evolution support -- it looks like
>>>>>>> it's the culprit behind most of the deps.
>>>>>>
>>>>>> Eugen, should I officially ask for a ekiga-gtk-only package?
>>>>>
>>>>> A similar report exists on debian bugzilla,
>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520830 .  The best
>>>>> solution is to add runtime detection (used by those who installed
>>>>> it, not used by the others), as shown here:
>>>>>
>>>>> "what you suggest ("ekiga: Dependancy on evolution-data-server
>>>>> should be
>>>>> removed or moved to additional package") should be possible after
>>>>> adding
>>>>> runtime detection of evolution-data-server to Ekiga."
>>>>>
>>>>> Could that be done in ekiga?
>>>>>
>>>> Make the evolution code a plugin... the basic framework is here...
>>>> we even already have a plugin loader!
>>>
>>> I made a bug report, not to forget it:
>>> http://bugzilla.gnome.org/show_bug.cgi?id=586147
>>
>> Julien has just fixed it on master: evolution (and kde, kab etc.) are
>> plugins now.  Julien, could you explain how this affects building (if
>> it does affect)?  Are these plugins generated as .so or what?  Are
>> they always built or what?
>
> Well, it's still possible not to build those pieces of code with the
> usual --disable switches : that didn't change.
>
> The difference is that now, when it's built, it's possible to package
> ekiga and those pieces separately ; the ekiga executable doesn't have
> those features (and doesn't link to the libs they depend on).

For information, debian snapshots contain now a plugin for evolution
(which is put in the same ekiga-snapshot package).

So you can install ekiga-snapshot without evolution-data-server.  But if
you have it, it will be used automatically, through the plugin.

Thanks to Julien who did it.

--
Eugen
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list