Julien Puydt a écrit :
Hi,
after days of fight, I managed to get a simpler program to crash like
ekiga yesterday evening. This night, I made that program simpler.
You'll find attached what's needed to reproduce the crash. You'll need
to unpack the tarball somewhere, and modify the EKIGA_DIR
Julien Puydt a écrit :
There is definitely a problem with gmref_ptr, but I still don't know
which :-/
I kicked all uses of gmref_inc/gmref_dec out of the GUI, and it doesn't
crash anymore. Sigh...
Snark
___
Ekiga-devel-list mailing list
Ekiga
Hi,
after days of fight, I managed to get a simpler program to crash like
ekiga yesterday evening. This night, I made that program simpler.
You'll find attached what's needed to reproduce the crash. You'll need
to unpack the tarball somewhere, and modify the EKIGA_DIR line to point
to your
Julien Puydt a écrit :
the crash-on-exit bug which cripples ekiga since too long.
I have no clue why. Help!
If :
- I compile out evolution-data-server ;
- I disconnect forcefully the GUI from the engine in the
rosteraddressbook windows (which makes ekiga unusable...) ;
- I put back
Julien Puydt a écrit :
sigc::bind_functor0,
sigc::bound_const_mem_functor2void, sigc::signal2void,
gmref_ptrEkiga::Book, gmref_ptrEkiga::Contact, sigc::nil,
gmref_ptrEkiga::Book const, gmref_ptrEkiga::Contact const,
gmref_ptrEvolution::Book, sigc::nil, sigc::nil, sigc::nil, sigc::nil,
sigc
Eugen Dedu a écrit :
Julien Puydt wrote:
Damien Sandras a écrit :
Multithreading ?
Perhaps you could check the thread name. What would be nice to do, is
being able to monitor the ref count value in real time for that object.
The lines of code which give that are next to each other
Hi,
here is the source of a backtrace dumper to follow each and every
gmref_inc/gmref_dec in ekiga (and can print THIS: for objects of
interest though that is commented out).
It uses nemiver-as-a-lib (needs svn from nemiver and snapshot from gdb,
and the target program can't print anything
Hi,
I committed log-printing code in ekiga -- and I need help to make sense
of it. This is very directly related to the crash-on-exit bug which
cripples ekiga since too long.
The problem is found in that piece of log :
void on_heap_updated(gmref_ptrEkiga::Cluster, gmref_ptrEkiga::Heap,
Damien Sandras a écrit :
Multithreading ?
Perhaps you could check the thread name. What would be nice to do, is
being able to monitor the ref count value in real time for that object.
The lines of code which give that are next to each other : they can't be
from different threads. And what
Damien Sandras a écrit :
Without feedback :
- do we consider that people are too lazy to test and that no test has
been done
- do we consider that it works well
?
Le mercredi 29 octobre 2008 à 23:19 +0100, yannick a écrit :
It's been less than a week!
I have personally been mostly
Heiser Michael a écrit :
I downloaded the ekiga 3.01 sources from the homepage an generated a
documentation via Doxygen. The documentation seem to be only about the
Ekiga-Engine.
So where can I find the code for DBUS handling to have a look at it?
The DBUS code in ekiga 3.x is mostly dead at
Hi,
I have still no news from anyone about the way other clients than
eyebeam store their resource-lists.
I still worked on the issue :
- I fixed a big memory leak in the current XCAP code ;
- I managed (five minutes ago after a very long fight) to get openXCAP
up and running on my box --
Peter Robinson a écrit :
Quick query, is there a reason why this release has added a direct
dependency to speex over the old release which only had the dep in
opal?
Opal's embedded version was very very old, if I remember well.
Snark
___
Hi,
I implemented basic XCAP+resource-lists code in trunk yesterday evening.
I would like to find several things :
(1) sites to connect to and check if the code behaves well, for testing
and compatibility to the server purposes ;
(2) sample resource-lists documents as created by other
Epelde Gorka a écrit :
So, I've found that for a videoconference scenario, Ekiga is an interesting
option. Right now, our platform is running on windows, so I'm interested in
having a stable version of Ekiga for windows and having a working
cross-building environment.
We do already build ekiga
Hi,
I would really like to progress on that bug : I have ideas for the
XCAP/resource-list code, but don't dare going through before I have a
reasonable way to manage memory in it (the RL::Cluster is going to be
pretty complex...).
It would be nice if you read the code (and the example
Jan Schampera a écrit :
Julien Puydt wrote:
It would be nice if you read the code (and the example code).
I see nothing wrong with the code - though, I'm not really a C++ guy
(but I understand it, of course).
What do you worry about?
I'm worried about the code not being nice and usable
Hi,
I committed very basic XCAP+resource-list to svn this afternoon. It's
not complete in any way, but it's still there.
It currently uses libsoup for the XCAP part.
You have to use --enable-xcap to enable it.
It will by default try to load the resource list at the uri
Jan Schampera a écrit :
Since some users reported buggy behaviour, I tested some 5 minutes:
- EVO: Add contact, enter Video URL: Nothing shows up in Ekiga
- EVO: Add contact, enter Businessphone Number: Shows up in Ekiga (as
Phone)
- Ekiga: Edit existing empty contact, add Video URI, Shows up
Damien Sandras a écrit :
We should remove bonobo. I had removed all the includes. The problem is
that it still is linked through libgnome or libgnomeui, thus we can not
get rid of it.
Let's get rid of libgnomeui libgnome then : they're supposed to die
anyway.
Snark
Peter Robinson a écrit :
We should remove bonobo. I had removed all the includes. The problem is
that it still is linked through libgnome or libgnomeui, thus we can not
get rid of it.
Let's get rid of libgnomeui libgnome then : they're supposed to die
anyway.
The only reason why we keep them
Peter Robinson a écrit :
Not so much push it up higher (I think we've moved to 2.12?) but
rather move some of the libgnome related stuff to the new GTK features
instead
http://live.gnome.org/ProjectRidley
I think we still use gnome_program_init, but the rest is gone already.
Snark
Damien Sandras a écrit :
OPAL and PTLIB have been branched for the Ekiga 3.00 release.
Please use the new branches and not SVN TRUNK anymore.
Is it possible to do the same for ekiga too?
I have a few patches for after 3.0 already.
And a few ideas too.
Snark
Damien Sandras a écrit :
A mix of both :
- ekiga depends on libopal and libpt
- libopal depends on libpt
- libpt depends on pt plugins
I disagree :
* ptlib could be used without plugins ;
* opal too probably (it provides its own plugins, doesn't it?) ;
* but ekiga definitely needs the
Jared D. McNeill a écrit :
The attached patch (against 20080907 snapshot) enables detection of
NetBSD on configure.ac. Apart from this change ekiga requires no further
changes to run on this platform.
It's in, thanks!
Snark
___
Ekiga-devel-list
Christopher Warner a écrit :
Yeah I remember playing around with the quicktime stuff a very long
time ago and I hit some hurdles with it because of my webcam at the
time. I was using some driver interface called MaCam which seems to be
the default driver for other webcams not associated with
Jan Schampera a écrit :
due to some discussions about this topic in chat and on the bugzilla,
here the official discussion thread ;-)
Which GTK+ to choose as platform for Ekiga 3.0?
My suggestion is 2.12, since it's relatively mature now, and part of
Debian Lenny.
I vote for 2.12.
Damien Sandras a écrit :
Le lundi 28 juillet 2008 à 21:41 +0200, Julien Puydt a écrit :
Hi,
I would need a way to setup ekiga with something in front of it, which
will send presence/status information on a pretty high rate.
The goal is to trigger the crash in sigc::trackable much, much more
Damien Sandras a écrit :
Le mardi 29 juillet 2008 à 10:05 +0200, Julien Puydt a écrit :
Damien Sandras a écrit :
Le lundi 28 juillet 2008 à 21:41 +0200, Julien Puydt a écrit :
Hi,
I would need a way to setup ekiga with something in front of it, which
will send presence/status information
Julien Puydt a écrit :
Running :
sipp -sn uas -aa
is supposed put sipp in server mode (-sn uas), and answer ok to
everything (-aa)...
Not sure uas is what I thought it was...
I have to dig further.
Snark
___
Ekiga-devel-list mailing list
Ekiga
Hi,
I would need a way to setup ekiga with something in front of it, which
will send presence/status information on a pretty high rate.
The goal is to trigger the crash in sigc::trackable much, much more
easily, to kill it.
I was thinking a pseudo-server could do the trick (ie: a false
Anacharsis a écrit :
Which version?
2.0.12
You should install LDAP to find other users with whom to connect.
Yes, I know, but I do not need to: we use h.323 inside LAN and we know
everybody by IP address (static IPs, no DHCP).
2.0.12 doesn't compile without LDAP... and I have to check
Julien Puydt a écrit :
2.0.12 doesn't compile without LDAP... and I have to check whether 3.0
will.
It's possible to compile 3.0 without LDAP.
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo
Hi,
I have fixed a few bugs in the gtk-only version lately ; are there known
issues with that version since then?
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Hi,
I fixed quite a few warnings, but there are still a few annoying ones :
A series of ambiguous 'else', where I'd rather see the code author add
braces, to be sure :
videooutput-manager-common.cpp:159
videooutput-manager-common.cpp:171
xwindow.cpp:749
xwindow.cpp:868
The compiler suggests
Matthias Schneider a écrit :
in my opinion all this dir stuff sucks a lot. I have added your path to the
list of searched dirs, thinking that this way forward will cost less boring
and useless work to me than the other possibilities. In case you feel like it
you could still report this as a
Matthias Schneider a écrit :
could you please try again?
As I told on IRC : ok.
(but I want it visible in the archives that you got it)
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
Matthias Schneider a écrit :
Quoting Julien Puydt [EMAIL PROTECTED]:
Hi,
I have a hard time compiling ptlib+opal+ekiga those days : since I
upgraded my libavcodec-dev package, avcodec.h is to be found in :
/usr/include/ffmpeg/libavcodec/avcodec.h
but is searched in :
libavcodec/avcodec.h
Julien Puydt a écrit :
Matthias Schneider a écrit :
Quoting Julien Puydt [EMAIL PROTECTED]:
Hi,
I have a hard time compiling ptlib+opal+ekiga those days : since I
upgraded my libavcodec-dev package, avcodec.h is to be found in :
/usr/include/ffmpeg/libavcodec/avcodec.h
but is searched
Do we have win32 ekiga snaps handy for that :
http://wiki.winehq.org/DogfoodChallenge
?
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Hi,
I have a hard time compiling ptlib+opal+ekiga those days : since I
upgraded my libavcodec-dev package, avcodec.h is to be found in :
/usr/include/ffmpeg/libavcodec/avcodec.h
but is searched in :
libavcodec/avcodec.h
ffmpeg/avcodec.h
in fact, if the configure script were doing things right,
Matthias Apitz a écrit :
El día Tuesday, May 20, 2008 a las 02:28:48PM +0200, Damien Sandras escribió:
Le mardi 20 mai 2008 à 14:25 +0200, Matthias Apitz a écrit :
Hello,
I've the following problem with the new copiled ekiga; it says on start
on sdterr:
Bad NAT type
does not present
Martin Ebourne a écrit :
On Mon, 2008-05-19 at 23:23 +0100, Peter Robinson wrote:
../../../../lib/engine/presence/local-roster/local-presentity.cpp:272:
error: no matching function for call to
'find(std::_Rb_tree_const_iteratorstd::basic_stringchar,
std::char_traitschar, std::allocatorchar ,
Martin Ebourne a écrit :
Fix trunk compilation on Fedora 9.
How does it compare to the patch already here :
http://bugzilla.gnome.org/show_bug.cgi?id=533266
(which I was going to apply when your mail arrived)
Snark
___
Ekiga-devel-list mailing list
Peter Robinson a écrit :
Does MacOS X come with a built-in SIP app, like it comes with a
built-in email app?
Yes, iChat, but its network is closed. :(
I've read that SIp is only used to established the RTP session But it can't
register to any SIp server I guess ?
So it's no Sip client built
Here it is :
/usr/include/opal/opal/rtpconn.h: In copy constructor
‘OpalRTPSessionManager::OpalRTPSessionManager(const
OpalRTPSessionManager)’:
/usr/include/opal/opal/rtpconn.h:160: warning: base class ‘class
PObject’ should be explicitly initialized in the copy constructor
Hi,
I just found a big problem (and fixed it) in the configuration handling
on non-gconf installations (which includes win32).
I'd like our dear win32 testers to tell me if things improved.
Snark
___
Ekiga-devel-list mailing list
Peter Robinson a écrit :
Just a fyi on the building ekiga as a rpm with the current Fedora 9.
Wouldn't you use a very recent g++ which has tighter include
requirements than previous versions?
Snark
___
Ekiga-devel-list mailing list
Hi,
I got a crash ; I suppose ekiga doesn't like when run on a non-networked
box...
Snark
PS: here is the trace:
Thread 17 (Thread 0xb3aa0b90 (LWP 19608)):
#0 0xb6af3209 in PListPSocket::front ()
from /usr/lib/libpt_linux_x86_r.so.2.3-beta0
#1 0xb6aefed4 in PSTUNClient::GetNatType ()
Damien Sandras a écrit :
If it is a crash in PTLIB or OPAL, it should be reported on their
bugtracker.
I see there have been quite a few changes since saturday : I'm
recompiling everything again to check.
Snark
___
Ekiga-devel-list mailing list
yannick a écrit :
Hi,
fabrice called me this morning (up to date Ekiga SVN on both sides)
he had a crash and me too. here is mine:
http://pastebin.ca/982088
Have a nice day ;)
Did someone hack on pstring this night?
Snark
___
Julien Puydt a écrit :
Did someone hack on pstring this night?
Did you both recompile pwlib, opal and ekiga freshly this morning?
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel
Damien Sandras a écrit :
No, it looks weird.
Indeed.
The code is this one :
PString token;
endpoint.SetUpCall (pc:*, dial_uri.c_str (), token);
I saw ; may I just ask why we extract the C string from a std::string
before calling a C++ method?
Snark
Damien Sandras a écrit :
Le samedi 12 avril 2008 à 11:26 +0200, Julien Puydt a écrit :
Damien Sandras a écrit :
No, it looks weird.
Indeed.
The code is this one :
PString token;
endpoint.SetUpCall (pc:*, dial_uri.c_str (), token);
I saw ; may I just ask why we extract the C string from
Damien Sandras a écrit :
I'm using code like this to ensure sane values:
SetAudioJitterDelay (PMAX (min_val, 20), PMIN (max_val, 1000));
That is wrong : you're protecting the call to SetAudioJitterDelay, not
the method itself!
If I have a method which receives an integer which shouldn't be
Damien Sandras a écrit :
The problem was that I dial from a separate thread and the URI is passed
as a const reference instead of using a copy of the string. But the
original variable is already destroyed when the thread begins its work
as that work is done in a separate thread!
It should
clients/stun.cpp: In member function 'virtual void GMStunClient::Main()':
clients/stun.cpp:337: error: 'class GMManager' has no member named
'GetCurrentAddress'
With svn snapshots one hour old :-/
Snark
___
Ekiga-devel-list mailing list
Damien Sandras a écrit :
I forgot to commit the stun.cpp file yesterday.
I just did it.
Thanks!
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Hi,
again, there is a problem with the bridge : it gets something from
gmconf, doesn't check before use, and triggers a floating point exception.
I'm not sure whether the issue is in ekiga or in opal though :
0x08132c71 in GMManager::set_video_options (this=0x8303238,
[EMAIL PROTECTED]) at
Matthias Schneider a écrit :
Quoting Damien Sandras [EMAIL PROTECTED]:
Le vendredi 11 avril 2008 à 11:26 +0200, Matthias Schneider a écrit :
Quoting Julien Puydt [EMAIL PROTECTED]:
Hi,
again, there is a problem with the bridge : it gets something from
gmconf, doesn't check before use
[EMAIL PROTECTED] a écrit :
I am using this tutorial to compile Ekiga.
http://wiki.ekiga.org/index.php/Compile_your_own_SVN_version_of_Ekiga_on_Ubuntu
Someone can help me? Here is the command line output when Ekiga Crash,
You did notice that it was SVN, hence unstable, not for any random
Damien Sandras a écrit :
http://www.ietf.org/internet-drafts/draft-kaplan-sip-four-oh-00.txt
April fool, I would say ;-)
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Carlos Hernandez a écrit :
Where can I donwload Ekiga 3.0 for windows?, can't find the link in ekiga.org
3.0 isn't released.
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Julien Puydt a écrit :
I committed preliminary call history code today. It won't make the
contacts appear in the addressbook yet, but will print some data in the
console.
I committed more complete call history code today ; as far as I know,
the last missing piece is correct status comments
Hi,
I was investigating the problems with gmconf-glib when I met this crash:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb45e7b90 (LWP 32657)]
GMAccountsEndpoint::Main (this=0x85f0e70) at
endpoints/accountshandler.cpp:131
131 if (accounts_iter-data) {
Palo S. a écrit :
There is just too much
competition in VOIP under Linux
You mean you know other VoIP apps which do H323+SIP in audio+video with
support for a wide range of devices and good stability under gnu/linux?
Snark
___
Ekiga-devel-list
Damien Sandras a écrit :
Le samedi 29 mars 2008 à 10:53 +0100, Julien Puydt a écrit :
5- the call duration is not accessible (it is not accessible with a
cellphone either, but I think it is a needed feature)
Indeed ; the question is : how to present it to the user.
A additional column
Julien Puydt a écrit :
And we'll have to decide what to show exactly :-)
Since I didn't get greeted by complaints either on irc or on this list,
I committed should-work code.
It's still time to complain if something looks wrong!
Snark
___
Ekiga
Martin Vladić a écrit :
what do you think about DTLS-SRTP? Some people (IETF) favours
DTLS-SRTP over ZRTP (which is already implemented in trunk version in
OPAL). What do you think about adding support for DTLS-SRTP in Ekiga?
Thank you for your opinions!
I'm all for it, as long as someone
Hi,
I committed preliminary call history code today. It won't make the
contacts appear in the addressbook yet, but will print some data in the
console.
I had correct data when trying with 500, so I think outgoing calls go
well -- but I'll obviously need reports from people :
- receiving
Wendell a écrit :
I am a noob and am running Ubuntu 7.10.
I have been using Skype and saw that Ekiga was installed automatically.
I decided to try it but it will not launch.
Possibly there are dependencies that were not loaded.
How can I add Ekiga site to the repositories so that I can get
Craig Southeren a écrit :
I've added code to the trunk revision of ptlib that implements this
functionality for Windows.
Simply add the following code to the PProcess::Main descendant
PString urlTypes(sip\nh323\nsips\nh323s);
if
Isn't it simpler than what I wrote :
http://hughsient.livejournal.com/52544.html
?
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
yannick a écrit :
As a matter of fact, using linux, pidgin and ekiga are competing for
handling sip:...
Pidgin does SIP !?
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
(1) Visitor functions
There are a number of objects which list others, and have a a visit
method, which generally looks like this :
void visit (sigc::slotvoid, VisitedObjectType visitor);
This is pretty handy when you want to loop on all the objects, but not
when you're trying to lay your hand
Martin Ebourne a écrit :
Address book related crash in latest ekiga, r5787. Happens every time on
startup and the following asserts are given:
(ekiga:17541): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT
(object)' failed
(ekiga:17541): libebook-CRITICAL **:
Julien Puydt a écrit :
Martin Ebourne a écrit :
Address book related crash in latest ekiga, r5787. Happens every time on
startup and the following asserts are given:
(ekiga:17541): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed
(ekiga:17541): libebook
Julien Puydt a écrit :
much
Should I proceed preparing patches?
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Damien Sandras a écrit :
Le dimanche 16 décembre 2007 à 15:20 +0100, Julien Puydt a écrit :
Julien Puydt a écrit :
much
Should I proceed preparing patches?
If the code is documented, yes.
If the code is undocumented, no.
I'll document...
Snark
Hi,
the problem with the current organization to display forms in ekiga is
that they appear as separate windows, ie: they don't depend on another
window.
(I) A solution: wide scale
The obvious solution is to make the forms find their way to the ui not
directly like this : Some::Component -
Sigh
Julien Puydt a écrit :
(I) A solution: wide scale
s/wide scale/large view/ ?
in which case the others isn't called.
s/is/are/ !
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo
Damien Sandras a écrit :
We have unfortunately nobody in the team able to fix that.
There's me, and I have the following bug about it :
http://bugzilla.gnome.org/show_bug.cgi?id=461512
But I need to find the time :-(
Snark
___
Ekiga-devel-list
Matthias Schneider a écrit :
Hi Peter,
it should be fixed by now, it seems Damien commited a file that was
referencing
some other files
that are still private to him ;-)
I guess he missed a :
svn add lib/engine/protocol/skel/Makefile.am
I really don't like cvssvn... it's way too easy to
Craig Southeren a écrit :
As described previously, PTLib is about to migrate the internal type
PBoolean the ANSI type bool. This will affect all member functions
that use BOOL parameters and are overrides of standard PTLib and Opal
functions.
Wonderful!
Snark
Craig Southeren a écrit :
Julien Puydt wrote:
Craig Southeren a écrit :
As described previously, PTLib is about to migrate the internal type
PBoolean the ANSI type bool. This will affect all member functions
that use BOOL parameters and are overrides of standard PTLib and Opal
Raquel Valle a écrit :
Hi, is it possible to use a function or a data, created in Ekiga, in a
function in Opal?
I'm working with the jitter buffer (in Opal) and I want to use a function
declared in gmconf.h (in Ekiga). Can I do that?
Unfortunately no.
Snark on #ekiga
Hi,
let me try to explain how menus are made gui-independent in the engine,
and how that can allow doing things off-process.
Let's consider an object in the engine, which wants to make some actions
available. It will do so by having a method populate_menu, which will
receive a single argument,
Kilian Krause a écrit :
At a first glance this is due to configure demanding these to be added
to LDFLAGS. If someone finds the time to go through these and strip it
down to only the required ones before me, please feel free to do so.
Isn't it pkg-config adding them? In that case, we can
Damien Sandras a écrit :
Le samedi 22 septembre 2007 à 21:58 +0200, Julien Puydt a écrit :
Hi,
are there bugs you noticed in the new contact code, which I should know
about, hunt and kill?
It is currently not possible to add a contact in the roster without
adding it first in the address
Hi,
are there bugs you noticed in the new contact code, which I should know
about, hunt and kill?
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Jan Schiefer a écrit :
http://bugzilla.gnome.org/show_bug.cgi?id=474692
We *do* receive notifications of new bugs : this wasn't necessary.
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
Hi,
I wrote a plugin, which works great... as long as you're not in a call!
And in a call, input works but output doesn't.
I'm pretty sure there's something stupid I forgot which makes it broken,
but I can't find why -- a fresher look will perhaps find the problem
right away :
Luca Capello a écrit :
Some problems on a up-to-date amd64 Debian sid.
ekiga-snapshot (20070827-03-sid.1) on an i386 box starts without problem
here.
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
SIEGERSTEIN a écrit :
Hi!
I'm using FreeBSD 6.2-RELEASE, and see something strange with ekiga.
Be default sound system FreeBSD using OSS (Linux for example ALSA)
The default device is /dev/dsp
If hacking /etc/sysctl.conf to:
hw.snd.pcm0.vchans=4
hw.snd.maxautovchans=4
you can make
Johan Brannlund wrote:
Hi. I noticed that ekiga does not allow selection of custom ALSA devices
defined in ~/.asoundrc. Since the snd-bt-sco module is gone in kernels
2.6.21 and newer, this means that Ekiga will not support bluetooth
headsets at all with the newest kernels, which will soon
Nobody commented on it on this ml, but I really think it's worth having
in the list archive :
Julien Puydt a écrit :
http://aruiz.typepad.com/siliconisland/2007/05/gtkwin32_amateu.html
http://aruiz.typepad.com/siliconisland/2007/05/tango_and_gtk_l.html
Snark
Gustavo Honorato a écrit :
I would like to know which SIP Stack is used to implement Ekiga and where
can I get it?
It opal ; should be on sourceforge. We do provide source tarball, though.
Snark
___
Ekiga-devel-list mailing list
f_sophia a écrit :
Hmmm... you should contact the translation team.
Unfortunatelly, it's impossible.
The eo-translation team of GNOME is almost dead.
[I'm a member].
I meant the gnome translation team :-)
Or can someone forward it ?
Please, someone just add to CVS.
Well, I know where
Hi,
since some of us are deep in it :
http://aruiz.typepad.com/siliconisland/2007/05/gtkwin32_amateu.html
Hope it helps,
Snark
___
Ekiga-devel-list mailing list
Ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Luca Capello a écrit :
I can confirm that my SONY DCR-PC55E [2] works out-of-the-box with the
avc1394 plugin, but it doesn't with the dc1394 one: it says that it
cannot access /dev/raw1394, but my user is in the correct group and in
fact Kino [3] works perfectly with that camcorder.
Eh... if
301 - 400 of 442 matches
Mail list logo