Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.4

[Mystilleef]

On Mon, May 14, 2012 at 11:50 AM, Olivier Crête
 wrote:
> Hi
>
> On Mon, 2012-05-14 at 11:43 -0400, Mystilleef wrote:
>> 1) For outgoing calls, calling TpCallChannel.accept
>> transitions the channel's state from "Pending_Initiator" to
>> "Initialised". How do I get the channel's state to
>> "Accepted" and "Active"? The docs say rakia is supposed to
>> do this automatically after the accept method is called. So
>> far, I'm having no luck. I'm using telepathy-rakia-0.7.4 on
>> Fedora rawhide.
>
> For outgoing calls, it goes to ACCEPTED/ACTIVE when the other side
> accepts the call. This is probably related to the next problem as it
> won't send the request to the other side before getting the local codecs
> and candidates.
>
>> 2) The Farstream TfChannel created from TpCallChannel does
>> not emit signals for media streaming. In particular, "fs-
>> conference-added" and "content-added" do not get emitted.
>> I'm not sure if this is related to issue 1 or if this is a
>> bug.
>
> This is strange... Look at the output of dbus-monitor maybe...
>
> --
> Olivier Crête
> olivier.cr...@collabora.com

I've extracted the sofiasip messages going through D-Bus when I try to
make a call.

http://pastebin.com/C5pH8R8m

It appears that the Call1 Stream media interface emits a
ReceivingStateChanged signal. However nothing happen in tp-farstream
as far as I can tell.

Here's what my tp-farstream media streaming code looks like.

http://pastebin.com/gXbtjKZZ
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.4

[Mystilleef]

On Sat, May 12, 2012 at 6:28 PM, Olivier Crête
 wrote:
> Hi,
>
> For the media part, the telepathy-farstream code is the same, but for the 
> client part, you have to request a Call1 channel instead of a StreamedMedia 
> channel. And so you have to use different APIs there. The new Call1 API 
> should be much easier to use, no need to mess around with the Group interface 
> for example.
>
> Olivier

Hello,

I can't get the new Call1 API to make outgoing/incoming SIP
calls. Maybe I don't know how to use the new API.

I'm having 2 problems.

1) For outgoing calls, calling TpCallChannel.accept
transitions the channel's state from "Pending_Initiator" to
"Initialised". How do I get the channel's state to
"Accepted" and "Active"? The docs say rakia is supposed to
do this automatically after the accept method is called. So
far, I'm having no luck. I'm using telepathy-rakia-0.7.4 on
Fedora rawhide.

2) The Farstream TfChannel created from TpCallChannel does
not emit signals for media streaming. In particular, "fs-
conference-added" and "content-added" do not get emitted.
I'm not sure if this is related to issue 1 or if this is a
bug.

I appreciate any help or clues.

Thanks
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] Problem with Telepathy Farstream, new Call API and SIP

[Mystilleef]

Hello,

I'm trying to port my app to the new Call API. I've changed
all the interfaces to use the New Call API. The docs say to
initiate an outgoing SIP call all I have to do is call the
Accept method.

However, when I call the accept method, nothing happens. The
CallChannel does change its call state from Pending to
Initialising to Initialized but never to Accepted or Active.
Also none of the tpfarstream signals, fs-conference-added or
content-added, are emitted. In fact, nothing happens after I
connect to those signals.

Is there something else I need to do to make an outgoing
SIP call?

Thanks
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.4

[Mystilleef]

Aha, cool thank you.

On Sat, May 12, 2012 at 6:28 PM, Olivier Crête
 wrote:
> Hi,
>
> For the media part, the telepathy-farstream code is the same, but for the 
> client part, you have to request a Call1 channel instead of a StreamedMedia 
> channel. And so you have to use different APIs there. The new Call1 API 
> should be much easier to use, no need to mess around with the Group interface 
> for example.
>
> Olivier
>
> Mystilleef  wrote:
>
>>With regards to using the new Call API, do I need to adjust my code
>>with telepathy-farstream, or will my old code just work fine?
>>
>>On Tue, May 8, 2012 at 8:03 PM, Brian Pepple
>> wrote:
>>> On Tue, 2012-05-08 at 13:07 -0400, Olivier Crête wrote:
>>>> Telepathy-Rakia development release 0.7.4, the "Call Me Maybe"
>>>> release, is now available.
>>>>
>>>> If you are using GNOME 3.4, please ship this release, as calls will
>>not
>>>> work with older releases.
>>>>
>>>> But be aware that there is one remaining problem, sometimes SIP
>>servers
>>>> stop forwarding call to us. I am unable to reproduce it with any SIP
>>>> server that is under my control, so I don't know what happens, any
>>help
>>>> is appreciated.
>>>
>>> Does tp-rakia have a component to file bugs against at
>>freedesktop.org?
>>> Looks like the latest release has a DSO Linking bug that causes the
>>> build to fail. Here's a snippet from the build log.
>>>
>>> 
>>> /usr/bin/ld: ./.libs/librakia-convenience.a(call-stream.o): undefined
>>> reference to symbol 'g_inet_address_new_from_string'
>>> /usr/bin/ld: note: 'g_inet_address_new_from_string' is defined in
>>> DSO /lib64/libgio-2.0.so.0 so try adding it to the linker command
>>line
>>> /lib64/libgio-2.0.so.0: could not read symbols: Invalid operation
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [telepathy-rakia] Error 1
>>> make[3]: *** Waiting for unfinished jobs
>>> /usr/bin/ld: ./.libs/librakia-convenience.a(call-stream.o): undefined
>>> reference to symbol 'g_inet_address_new_from_string'
>>> /usr/bin/ld: note: 'g_inet_address_new_from_string' is defined in
>>> DSO /lib64/libgio-2.0.so.0 so try adding it to the linker command
>>line
>>> /lib64/libgio-2.0.so.0: could not read symbols: Invalid operation
>>> collect2: error: ld returned 1 exit status
>>> 
>>>
>>> If I have a little free time tomorrow, I'll see if I can whip up a
>>quick
>>> patch to fix this.
>>>
>>> Later,
>>> /B
>>> --
>>> Brian Pepple 
>>>
>>> https://fedoraproject.org/wiki/User:Bpepple
>>> gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
>>> BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
>>>
>>> ___
>>> telepathy mailing list
>>> telepathy@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/telepathy
>>>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.4

[Mystilleef]

With regards to using the new Call API, do I need to adjust my code
with telepathy-farstream, or will my old code just work fine?

On Tue, May 8, 2012 at 8:03 PM, Brian Pepple  wrote:
> On Tue, 2012-05-08 at 13:07 -0400, Olivier Crête wrote:
>> Telepathy-Rakia development release 0.7.4, the "Call Me Maybe"
>> release, is now available.
>>
>> If you are using GNOME 3.4, please ship this release, as calls will not
>> work with older releases.
>>
>> But be aware that there is one remaining problem, sometimes SIP servers
>> stop forwarding call to us. I am unable to reproduce it with any SIP
>> server that is under my control, so I don't know what happens, any help
>> is appreciated.
>
> Does tp-rakia have a component to file bugs against at freedesktop.org?
> Looks like the latest release has a DSO Linking bug that causes the
> build to fail. Here's a snippet from the build log.
>
> 
> /usr/bin/ld: ./.libs/librakia-convenience.a(call-stream.o): undefined
> reference to symbol 'g_inet_address_new_from_string'
> /usr/bin/ld: note: 'g_inet_address_new_from_string' is defined in
> DSO /lib64/libgio-2.0.so.0 so try adding it to the linker command line
> /lib64/libgio-2.0.so.0: could not read symbols: Invalid operation
> collect2: error: ld returned 1 exit status
> make[3]: *** [telepathy-rakia] Error 1
> make[3]: *** Waiting for unfinished jobs
> /usr/bin/ld: ./.libs/librakia-convenience.a(call-stream.o): undefined
> reference to symbol 'g_inet_address_new_from_string'
> /usr/bin/ld: note: 'g_inet_address_new_from_string' is defined in
> DSO /lib64/libgio-2.0.so.0 so try adding it to the linker command line
> /lib64/libgio-2.0.so.0: could not read symbols: Invalid operation
> collect2: error: ld returned 1 exit status
> 
>
> If I have a little free time tomorrow, I'll see if I can whip up a quick
> patch to fix this.
>
> Later,
> /B
> --
> Brian Pepple 
>
> https://fedoraproject.org/wiki/User:Bpepple
> gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
> BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E
>
> ___
> telepathy mailing list
> telepathy@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Does SIP work with the new Farstream

[Mystilleef]

Nevermind, after a reboot, everything works again. Weird.

On Sun, Apr 29, 2012 at 6:30 PM, Mystilleef  wrote:
> Hello,
>
> I decided, very reluctantly, to port my sip client to
> telepathy-farstream yesterday because fedora was whining about
> telepathy-farsight being obsolete. After hours of trial and error, it
> finally worked! Today, after a reboot, the client fails to connect to
> the server. Then I release the new telepathy modules may be using the
> new Call APIs. I tested Empathy to see if it could connect to the SIP
> server. It couldn't. So has anyone successfully made calls using SIP
> with the new Farstream/Call APIs? I've also noticed that
> telepathy-rakia just randomly exits (crashes?).
>
> Here's rakia's debug log: http://pastebin.com/CZbYgKjs
>
> Here are the relevant packages I have installed
>
> Installed Packages
> Name        : telepathy-farstream
> Arch        : i686
> Version     : 0.4.0
> Release     : 2.fc18
> Size        : 190 k
> Repo        : installed
> From repo   : rawhide
> Summary     : Telepathy client library to handle Call channels
> URL         : http://telepathy.freedesktop.org/wiki/Telepathy-Farsight
> License     : LGPLv2+
> Description : telepathy-farstream is a Telepathy client library that
> uses Farstream to handle
>            : Call channels.
>
> Name        : telepathy-glib
> Arch        : i686
> Version     : 0.18.1
> Release     : 1.fc18
> Size        : 2.4 M
> Repo        : installed
> From repo   : rawhide
> Summary     : GLib bindings for Telepathy
> URL         : http://telepathy.freedesktop.org/wiki/FrontPage
> License     : LGPLv2+
> Description : Telepathy-glib is the glib bindings for the telepathy
> unified framework
>            : for all forms of real time conversations, including
> instant messaging, IRC,
>            : voice calls and video calls.
>
> Name        : telepathy-rakia
> Arch        : i686
> Version     : 0.7.3
> Release     : 2.fc17
> Size        : 224 k
> Repo        : installed
> From repo   : rawhide
> Summary     : SIP connection manager for Telepathy
> URL         : http://telepathy.freedesktop.org/wiki/Components
> License     : LGPLv2+
> Description : telepathy-rakia is a SIP connection manager for the Telepathy
>            : framework based on the SofiaSIP-stack.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] Does SIP work with the new Farstream

[Mystilleef]

Hello,

I decided, very reluctantly, to port my sip client to
telepathy-farstream yesterday because fedora was whining about
telepathy-farsight being obsolete. After hours of trial and error, it
finally worked! Today, after a reboot, the client fails to connect to
the server. Then I release the new telepathy modules may be using the
new Call APIs. I tested Empathy to see if it could connect to the SIP
server. It couldn't. So has anyone successfully made calls using SIP
with the new Farstream/Call APIs? I've also noticed that
telepathy-rakia just randomly exits (crashes?).

Here's rakia's debug log: http://pastebin.com/CZbYgKjs

Here are the relevant packages I have installed

Installed Packages
Name: telepathy-farstream
Arch: i686
Version : 0.4.0
Release : 2.fc18
Size: 190 k
Repo: installed
>From repo   : rawhide
Summary : Telepathy client library to handle Call channels
URL : http://telepathy.freedesktop.org/wiki/Telepathy-Farsight
License : LGPLv2+
Description : telepathy-farstream is a Telepathy client library that
uses Farstream to handle
: Call channels.

Name: telepathy-glib
Arch: i686
Version : 0.18.1
Release : 1.fc18
Size: 2.4 M
Repo: installed
>From repo   : rawhide
Summary : GLib bindings for Telepathy
URL : http://telepathy.freedesktop.org/wiki/FrontPage
License : LGPLv2+
Description : Telepathy-glib is the glib bindings for the telepathy
unified framework
: for all forms of real time conversations, including
instant messaging, IRC,
: voice calls and video calls.

Name: telepathy-rakia
Arch: i686
Version : 0.7.3
Release : 2.fc17
Size: 224 k
Repo: installed
>From repo   : rawhide
Summary : SIP connection manager for Telepathy
URL : http://telepathy.freedesktop.org/wiki/Components
License : LGPLv2+
Description : telepathy-rakia is a SIP connection manager for the Telepathy
: framework based on the SofiaSIP-stack.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] telepathy-rakia not working (Was: ANNOUNCE: telepathy-rakia 0.7.2)

[Mystilleef]

Nevermind, I figured it out. Apparently, the protocol name still remains
sofiasip not rakia. I changed it to rakia thats why I was having problems.

Thanks


On Wednesday, October 26, 2011, wrote:

> Hi,
>
> > -Original Message-
> > From: ext Mystilleef [mailto:mystill...@gmail.com ]
> > Sent: 26 October, 2011 18:57
> > To: Zabaluev Mikhail (Nokia-MP/Helsinki)
> > Cc: telepathy@lists.freedesktop.org 
> > Subject: Re: [Telepathy] telepathy-rakia not working (Was: ANNOUNCE:
> > telepathy-rakia 0.7.2)
> >
> > Thanks, with your help, I enabled debugging and got the rakia process to
> > persist. My app is still offline. Here is the pertinent debug
> information.
> > In
> > particular, the following line looks strange. Any ideas?
> >
> > ** DEBUG: outbound(0x8c20620): FAILED to validate
> > 
> > ** DEBUG: outbound(0x8c20620): FAILED with 200 OK
>
> This is harmless. In fact this log shows that telepathy-rakia has
> successfully
> connected.
>
> Can you capture the dbus log with dbus-monitor --session (filtering
> irrelevant
> traffic if needed for privacy reasons) and send it to me?
>
> Best regards,
>  Mikhail
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] telepathy-rakia not working (Was: ANNOUNCE: telepathy-rakia 0.7.2)

[Mystilleef]

freedesktop.DBus',member='NameOwnerChanged',arg0='org.freedesktop.Telepathy.ChannelDispatcher'"
signal sender=:1.125 -> dest=(null destination) serial=148
path=/org/freedesktop/Telepathy/Account/rakia/sip/_31295977e0_40sipgate_2ecom0;
interface=org.freedesktop.Telepathy.Account;
member=AccountPropertyChanged
   array [
  dict entry(
 string "Connection"
 variant object path "/"
  )
  dict entry(
 string "ConnectionStatusReason"
 variant uint32 1
  )
  dict entry(
 string "ConnectionStatus"
 variant uint32 1
  )
  dict entry(
 string "ConnectionErrorDetails"
 variant array [
]
  )
  dict entry(
 string "ConnectionError"
 variant string ""
  )
   ]
signal sender=org.freedesktop.DBus -> dest=(null destination)
serial=76 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=NameOwnerChanged
   string ":1.139"
   string ""
   string ":1.139"
method call sender=:1.139 -> dest=org.freedesktop.DBus serial=1
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=Hello
method call sender=:1.139 -> dest=org.freedesktop.DBus serial=2
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=RequestName
   string "org.freedesktop.Telepathy.ConnectionManager.sofiasip"
   uint32 4
signal sender=org.freedesktop.DBus -> dest=(null destination)
serial=77 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=NameOwnerChanged
   string ":1.139"
   string ":1.139"
   string ""
signal sender=:1.125 -> dest=(null destination) serial=150
path=/org/freedesktop/Telepathy/Account/rakia/sip/_31295977e0_40sipgate_2ecom0;
interface=org.freedesktop.Telepathy.Account;
member=AccountPropertyChanged
   array [
  dict entry(
 string "Connection"
 variant object path "/"
  )
  dict entry(
 string "ConnectionStatusReason"
 variant uint32 2
  )
  dict entry(
 string "ConnectionStatus"
 variant uint32 2
  )
  dict entry(
 string "ConnectionErrorDetails"
 variant array [
]
  )
  dict entry(
 string "ConnectionError"
 variant string ""
  )
   ]
signal sender=:1.125 -> dest=(null destination) serial=151
path=/com/nokia/MissionControl/requests/r1;
interface=org.freedesktop.Telepathy.ChannelRequest; member=Failed
   string "org.freedesktop.Telepathy.Error.Disconnected"
   string "Account rakia/sip/_31295977e0_40sipgate_2ecom0 disconnected
with reason 2"
method call sender=:1.134 -> dest=org.freedesktop.DBus serial=58
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=RemoveMatch
   string 
"type='signal',sender=':1.125',path='/com/nokia/MissionControl/requests/r1',interface='org.freedesktop.Telepathy.ChannelRequest'"
method call sender=:1.134 -> dest=org.freedesktop.DBus serial=59
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=RemoveMatch
   string 
"type='signal',sender='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.125'"
===


On Wed, Oct 26, 2011 at 12:11 PM,   wrote:
> Hi,
>
>> -Original Message-
>> From: ext Mystilleef [mailto:mystill...@gmail.com]
>> Sent: 26 October, 2011 18:57
>> To: Zabaluev Mikhail (Nokia-MP/Helsinki)
>> Cc: telepathy@lists.freedesktop.org
>> Subject: Re: [Telepathy] telepathy-rakia not working (Was: ANNOUNCE:
>> telepathy-rakia 0.7.2)
>>
>> Thanks, with your help, I enabled debugging and got the rakia process to
>> persist. My app is still offline. Here is the pertinent debug information.
>> In
>> particular, the following line looks strange. Any ideas?
>>
>> ** DEBUG: outbound(0x8c20620): FAILED to validate
>> 
>> ** DEBUG: outbound(0x8c20620): FAILED with 200 OK
>
> This is harmless. In fact this log shows that telepathy-rakia has successfully
> connected.
>
> Can you capture the dbus log with dbus-monitor --session (filtering irrelevant
> traffic if needed for privacy reasons) and send it to me?
>
> Best regards,
>  Mikhail
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] telepathy-rakia not working (Was: ANNOUNCE: telepathy-rakia 0.7.2)

[Mystilleef]

Thanks, with your help, I enabled debugging and got the
rakia process to persist. My app is still offline. Here is
the pertinent debug information. In particular, the
following line looks strange. Any ideas?

** DEBUG: outbound(0x8c20620): FAILED to validate

** DEBUG: outbound(0x8c20620): FAILED with 200 OK


=

** DEBUG: rakia_base_connection_sofia_callback: event nua_i_outbound: 101
NAT detected
** DEBUG: rakia_base_connection_sofia_callback: connection 0x8c1b058,
refcount 1
** DEBUG: rakia_base_connection_sofia_callback: dispatching to target
0x8c1b058 (handle 0x8c20620)
** DEBUG: rakia_base_connection_sofia_callback: event nua_i_outbound for
target 0x8c1b058 was not consumed
** DEBUG: rakia_base_connection_sofia_callback: exit
** DEBUG: rakia_base_connection_sofia_callback: event nua_r_register: 401
Unauthorized
** DEBUG: rakia_base_connection_sofia_callback: connection 0x8c1b058,
refcount 1
** DEBUG: rakia_base_connection_sofia_callback: dispatching to target
0x8c1b058 (handle 0x8c20620)
** DEBUG: priv_handle_auth: response presents an authentication challenge
** DEBUG: priv_handle_auth: using the primary auth credentials
** DEBUG: priv_handle_auth_continue: Digest-authenticating user='1295977e0'
realm="sipgate.com"
** DEBUG: rakia_base_connection_sofia_callback: exit
** DEBUG: rakia_base_connection_sofia_callback: event nua_r_register: 200 OK
** DEBUG: rakia_base_connection_sofia_callback: connection 0x8c1b058,
refcount 1
** DEBUG: rakia_base_connection_sofia_callback: dispatching to target
0x8c1b058 (handle 0x8c20620)
** DEBUG: rakia_connection_nua_r_register_cb: successfully registered to the
network
tp-glib/connection-DEBUG: tp_base_connection_change_status: was 1, now 0,
for reason 1
tp-glib/connection-DEBUG: tp_base_connection_change_status: emitting
status-changed to 0, for reason 1
** DEBUG: rakia_base_connection_sofia_callback: exit
** DEBUG: conn_get_alias: handle 1 got alias 129597...@sipgate.com
** DEBUG: rakia_connection_set_aliases: setting alias for self: 1295977e0

Gtk-WARNING **: Unknown property: GtkGrid.n-rows
** DEBUG: outbound(0x8c20620): FAILED to validate

** DEBUG: outbound(0x8c20620): FAILED with 200 OK
** DEBUG: rakia_base_connection_sofia_callback: event nua_i_outbound: 200 OK
** DEBUG: rakia_base_connection_sofia_callback: connection 0x8c1b058,
refcount 1
** DEBUG: rakia_base_connection_sofia_callback: dispatching to target
0x8c1b058 (handle 0x8c20620)
** DEBUG: rakia_base_connection_sofia_callback: event nua_i_outbound for
target 0x8c1b058 was not consumed
** DEBUG: rakia_base_connection_sofia_callback: exit
** DEBUG: nta_agent: tport: Bad message
** DEBUG: nta_agent: tport: Bad message
** DEBUG: outbound(0x8c20620): FAILED to validate

** DEBUG: outbound(0x8c20620): FAILED with 200 OK
** DEBUG: rakia_base_connection_sofia_callback: event nua_i_outbound: 200 OK
** DEBUG: rakia_base_connection_sofia_callback: connection 0x8c1b058,
refcount 1
** DEBUG: rakia_base_connection_sofia_callback: dispatching to target
0x8c1b058 (handle 0x8c20620)
** DEBUG: rakia_base_connection_sofia_callback: event nua_i_outbound for
target 0x8c1b058 was not consumed
** DEBUG: rakia_base_connection_sofia_callback: exit

=

On Wednesday, October 26, 2011, wrote:

> Hi,
>
> > -Original Message-
> > From: ext Mystilleef [mailto:mystill...@gmail.com ]
> > Sent: 26 October, 2011 17:39
> > To: Zabaluev Mikhail (Nokia-MP/Helsinki)
> > Cc: telepathy@lists.freedesktop.org ;
> ftp-rele...@lists.freedesktop.org 
> > Subject: Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.2
> >
> > Fedora rawhide now uses telepathy-rakia version 0.7.2
> >
> > Since the change from sofia to rakia my app has stopped working. It's
> always
> > offline.
> >
> > It turns out Mission Control is not starting the telepathy- rakia
> process.
> > Or the
> > process is timing out. Starting the process manually results in the
> > following
> > error.
> >
> > lateef@submission ~/D/teletest> /usr/libexec/telepathy-rakia
> > tp-glib-DEBUG: started version 0.7.2 (telepathy-glib version 0.16.0)
> > tp-glib-DEBUG: no connections, and timed out
> > tp-glib-Message: Exiting
>
> You can make it run persistently by exporting RAKIA_PERSIST=1.
> Also export RAKIA_DEBUG=all for more information in the log.
>
> You can also see the logs in the debug window in Empathy, if you select the
> "rakia" component (or it might still be listed as "sofiasip", I did not
> check
> yet).
>
> Hope this helps,
>  Mikhail
>
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] ANNOUNCE: telepathy-rakia 0.7.2

[Mystilleef]

Hello,

Fedora rawhide now uses telepathy-rakia version 0.7.2

Since the change from sofia to rakia my app has stopped
working. It's always offline.

It turns out Mission Control is not starting the telepathy-
rakia process. Or the process is timing out. Starting the
process manually results in the following error.

lateef@submission ~/D/teletest> /usr/libexec/telepathy-rakia
tp-glib-DEBUG: started version 0.7.2 (telepathy-glib version 0.16.0)
tp-glib-DEBUG: no connections, and timed out
tp-glib-Message: Exiting

Any ideas?

Thanks




On Tuesday, September 6, 2011, Mikhail Zabaluev wrote:

> A Telepathy-Rakia development release 0.7.2, the "Correcting People"
> release, is now available.
>
> Tarball:
> http://telepathy.freedesktop.**org/releases/telepathy-rakia/**
> telepathy-rakia-0.7.2.tar.gz
> Signature:
> http://telepathy.freedesktop.**org/releases/telepathy-rakia/**
> telepathy-rakia-0.7.2.tar.gz.**asc
>
> News and enhancements:
>
> - The project is renamed to Telepathy-Rakia.
> - Updated Channel.Interface.DTMF implementation to spec 0.21.3.
>  * This means dialstrings!
> - Improved and slightly optimized logging.
> - Added Messages properties to immutable properties.
>
> This release also includes fixes and enhancements done to the stable
> telepathy-sofiasip releases up to version 0.6.8.
>
> Наздраве!
>  Mikhail
> __**_
> telepathy mailing list
> telepathy@lists.freedesktop.org
> http://lists.freedesktop.org/**mailman/listinfo/telepathy
>
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Announce: telepathy-glib 0.15.6

[Mystilleef]

On Monday, October 3, 2011, Xavier Claessens wrote:

>
> It should have no effect on PyGI since those deprecated APIs where
> already annotated with (skip) anyway.
>
> However, I've been told that a commit[1] breaks introspection because
> order in which gi-parser takes files matters. Arguably it could be a
> gobject-introspection bug, but I'll probably make a 0.15.6.1 workaround
> by reverting that commit today.
>
> Could you please test if reverting the commit fix your issue as well?
>
>

Reverting the commit fixes my issue.

Thanks
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Announce: telepathy-glib 0.15.6

[Mystilleef]

On Friday, September 30, 2011, Xavier Claessens wrote:

>
> Deprecations:
>
> • tp_account_prepare_{async,finish} replaced by
> tp_proxy_prepare_{async,finish}
> • tp_account_manager_prepare_{async,finish} replaced by
>  tp_proxy_prepare_{async,finish}
>
>

 How does this translate in PyGI? My app now fails with an attribute error
during account manager preparation.

Isn't account manager and account a subclass of tp proxy?

=
lateef@submission ~/D/teletest> python
Python 2.7.2 (default, Sep 30 2011, 20:53:59)
[GCC 4.6.1 20110908 (Red Hat 4.6.1-9)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gi.repository.TelepathyGLib import AccountManager


>>> am = AccountManager.dup()
>>> am.prepare_async
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'AccountManager' object has no attribute 'prepare_async'
==
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] tpfarsight (Python) and GObject Introspection Incompatibilities

[Mystilleef]

2011/8/24 Olivier Crête :
> On Wed, 2011-08-24 at 10:52 -0400, Mystilleef wrote:
>> 2011/8/24 Olivier Crête :
>> > Hi,
>> >
>> > On Wed, 2011-08-24 at 08:55 +0200, Tomeu Vizoso wrote:
>> >> On Wed, Aug 24, 2011 at 08:35, Mystilleef  wrote:
>> >> > Hello,
>> >> >
>> >> > My application suddenly stopped working after an upgrade. So I spent
>> >> > the better part of today trying to figure out why. It turns out the
>> >> > latest version of gobject-introspection is very strict and doesn't
>> >> > allow mixing non-introspectable python bindings with introspectable
>> >> > ones. Fortunately, my app runs its tpfarsight streamer in its own
>> >> > process. So it was easy to revert to using old school python bindings
>> >> > for gobject.
>> >> >
>> >> > To cut the long story short. I think the python bindings for
>> >> > telepathy-farsight and or farsight wouldn't work with the latest PyGI
>> >> > and gobject-introspection. Is this a known issue? Should I file a bug
>> >> > report?
>> >>
>> >> I'm not maintainer of those modules, but I think that if you think the
>> >> bug is in those, you should put it in bugzilla. If you think the
>> >> problem lies in pygobject or gobject-introspection, use
>> >> bugzilla.gnome.org instead.
>> >
>> > I maintain the python bindings for farsight and tp-fs, the reason
>> > they're not using gi yet is that GStreamer isn't and probably won't be
>> > before 1.0.
>> >
>>
>> Cool! I think they might have started to use gi.  A look at
>> dir(gi.repository.Gst) shows many of the most important elements are
>> available. How well they work is a completely different story. I'll
>> test it out later when I have time.
>
> Except that I think important bits like the buffers, events and queries
> are not covered (because they're GstMiniObjects which are not GObjects).
>
>

Aha, I didn't catch that.

Lateef
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] tpfarsight (Python) and GObject Introspection Incompatibilities

[Mystilleef]

2011/8/24 Olivier Crête :
> Hi,
>
> On Wed, 2011-08-24 at 08:55 +0200, Tomeu Vizoso wrote:
>> On Wed, Aug 24, 2011 at 08:35, Mystilleef  wrote:
>> > Hello,
>> >
>> > My application suddenly stopped working after an upgrade. So I spent
>> > the better part of today trying to figure out why. It turns out the
>> > latest version of gobject-introspection is very strict and doesn't
>> > allow mixing non-introspectable python bindings with introspectable
>> > ones. Fortunately, my app runs its tpfarsight streamer in its own
>> > process. So it was easy to revert to using old school python bindings
>> > for gobject.
>> >
>> > To cut the long story short. I think the python bindings for
>> > telepathy-farsight and or farsight wouldn't work with the latest PyGI
>> > and gobject-introspection. Is this a known issue? Should I file a bug
>> > report?
>>
>> I'm not maintainer of those modules, but I think that if you think the
>> bug is in those, you should put it in bugzilla. If you think the
>> problem lies in pygobject or gobject-introspection, use
>> bugzilla.gnome.org instead.
>
> I maintain the python bindings for farsight and tp-fs, the reason
> they're not using gi yet is that GStreamer isn't and probably won't be
> before 1.0.
>

Cool! I think they might have started to use gi.  A look at
dir(gi.repository.Gst) shows many of the most important elements are
available. How well they work is a completely different story. I'll
test it out later when I have time.

>>> Gst.version_string()
'GStreamer 0.10.35'

Lateef
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] tpfarsight (Python) and GObject Introspection Incompatibilities

[Mystilleef]

Hello,

My application suddenly stopped working after an upgrade. So I spent
the better part of today trying to figure out why. It turns out the
latest version of gobject-introspection is very strict and doesn't
allow mixing non-introspectable python bindings with introspectable
ones. Fortunately, my app runs its tpfarsight streamer in its own
process. So it was easy to revert to using old school python bindings
for gobject.

To cut the long story short. I think the python bindings for
telepathy-farsight and or farsight wouldn't work with the latest PyGI
and gobject-introspection. Is this a known issue? Should I file a bug
report?

These are the versions of the relevant libraries I have installed.

gobject-introspection 1.29.16
telepathy-farsight 0.0.19
telepathy-farsight-python 0.0.19
telepathy-glib 0.15.5
pygobject3 2.90.2

Lateef
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] empathy-2.32.2 refuses to call through SIP

[Mystilleef]

On Tue, Jun 21, 2011 at 4:28 PM, Yuri  wrote:
> I am on FreeBSD-8.2. I have installed sofia-sip and telepathy-sofiasip.
>
> empathy is able to connect with my SIP account and has status 'Available'.
> However, when I am trying to place a call (Chat->New Call) SIP account in
> combobox is grayed out.
>
> What might be the reason of this?
> Maybe there are some prerequisites that are not met? Maybe some dependencies
> have to have some compile flags?
>
> Thank you,
> Yuri

Set the udp flag in the advanced settings.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] gst.LinkError in Telepathy Farsight

[Mystilleef]

2011/6/17 Olivier Crête :
> If you get a segfault from python code, it means there is a bug in the C
> code somewhere..
>


In gstreamer or tp-farsigh?


> Can you post the smallest possible example that crashes somewhere ?
>


I'm assuming you want a working example and not just snippet
code? If so, I don't know of a simple way to simulate
incoming SIP channels. Here's the complete code that handles
media streaming using tp-farsight:

http://pastebin.com/pnWWJrq9

I don't mind sending you my current code base if you want to
test it yourself. Since I'm using PyGI tp-glib, you have to
patch PyGObject and use Xavier's tp-glib contact-list
branch to get it working. You also need an SIP account.

PyGObject patch: https://bugzilla.gnome.org/show_bug.cgi?id=652115

Xavier's contact-list branch:
http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=contact-list


> Btw, this belongs on the gstreamer mailing list
>


I think it belongs here. I figured the most qualified people
to help me with tp-farsight would be the telepathy
community. Besides, users having problems streaming media
using tp- farsight are most likely to search this mailing
list. As a bonus they have "partially working" example code
they can study.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] gst.LinkError in Telepathy Farsight

[Mystilleef]

2011/6/17 Olivier Crête :
> You want to do it in this order:
>
> def __stream_created_cb(self, channel, stream):
>  print "Start of stream created!"
>  stream.connect("src-pad-added", self.__src_pad_added_cb)
>  srcpad = stream.get_property ("sink-pad")
>  from gst import element_factory_make, STATE_PLAYING
>  src = element_factory_make("audiotestsrc")
>  src.set_property("is-live", True)
>  self.__pipeline.add(src)
>  src.get_pad("src").link(srcpad)
>  src.set_state(STATE_PLAYING)
>

Still crashes. I spent all morning trying different orders. It crashes
or gives me a gst.LinkError, if the state is not put in an idle
handler. The only thing that solved it for me is putting the state in
the idle handler.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] gst.LinkError in Telepathy Farsight

[Mystilleef]

2011/6/17 Olivier Crête :
> Hi,
>
> On Fri, 2011-06-17 at 18:04 -0400, Mystilleef wrote:
>> On Fri, Jun 17, 2011 at 5:51 PM, Tiago Katcipis  wrote:
>> >> 
>> >>        def __stream_created_cb(self, channel, stream):
>> >>                print "Start of stream created!"
>> >>                stream.connect("src-pad-added", self.__src_pad_added_cb)
>> >>                srcpad = stream.get_property ("sink-pad")
>> >>                from gst import element_factory_make, STATE_PLAYING
>> >>                src = element_factory_make("audiotestsrc")
>> >>                src.get_pad("src").link(srcpad)
>> >>                src.set_property("is-live", True)
>> >>                src.set_state(STATE_PLAYING)
>> >>                self.__pipeline.add(src)
>> >
>> > here it seems to be the problem, self.__pipeline.add(src) and
>> > src.set_state(STATE_PLAYING) should be called before you call
>> > src.get_pad("src").link(srcpad). You can link pads of elements that belong
>> > to the same pipeline (bin) and are on the same state.
>>
>> I think you're right. I also had to set "STATE_PLAYING" in an idle handler.
>
> You don't have to change the state in a idle handler, it should matter.
>

It crashes with the following error if I don't put it in an idle handler

===
(run:14061): GStreamer-CRITICAL **:
Trying to dispose element autoaudiosrc0, but it is in PLAYING instead
of the NULL state.
You need to explicitly set elements to the NULL state before
dropping the final reference, to allow them to clean up.
This problem may also be caused by a refcounting bug in the
application or some element.

(run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio)
_tf_stream_bus_message: Codecs changed
(run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio)
_tf_stream_try_sending_codecs: called (send_local:0 send_supported:0)
(run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio)
_tf_stream_try_sending_codecs: 0: audio PCMU clock:8000 channels:0
(run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio)
_tf_stream_try_sending_codecs: 101: audio telephone-event clock:8000
channels:0 events=0-15
(run:14061): tp-fs-DEBUG: stream 0 0xa25b020 (audio)
_tf_stream_bus_message: Send codec changed: 0: audio PCMU clock:8000
channels:0 params:(nil)
fish: Job 1, “./run ” terminated by signal SIGSEGV (Address boundary error)
==
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] gst.LinkError in Telepathy Farsight

[Mystilleef]

Thanks for your response Tiago.

On Fri, Jun 17, 2011 at 5:51 PM, Tiago Katcipis  wrote:
> Hi,
>
> On Fri, Jun 17, 2011 at 9:54 AM, Mystilleef  wrote:
>>
>> I'm getting the following error with tp-farsight
>>
>> =
>> Traceback (most recent call last):
>>  File "/home/lateef/teletest/MediaChannelStreamer.py", line 54, in
>> __stream_created_cb
>>    src.get_pad("src").link(srcpad)
>> gst.LinkError: > GstPadLinkReturn>
>
> I think this happens because you are trying to link two pads and the
> elements that owns the pads are not inside the same pipeline (the same bin
> to me more exact).
>
>>
>> =
>>
>> The code in question:
>>
>> 
>>        def __stream_created_cb(self, channel, stream):
>>                print "Start of stream created!"
>>                stream.connect("src-pad-added", self.__src_pad_added_cb)
>>                srcpad = stream.get_property ("sink-pad")
>>                from gst import element_factory_make, STATE_PLAYING
>>                src = element_factory_make("audiotestsrc")
>>                src.get_pad("src").link(srcpad)
>>                src.set_property("is-live", True)
>>                src.set_state(STATE_PLAYING)
>>                self.__pipeline.add(src)
>
> here it seems to be the problem, self.__pipeline.add(src) and
> src.set_state(STATE_PLAYING) should be called before you call
> src.get_pad("src").link(srcpad). You can link pads of elements that belong
> to the same pipeline (bin) and are on the same state.
>


I think you're right. I also had to set "STATE_PLAYING" in an idle handler.


def __stream_created_cb(self, channel, stream):
stream.connect("src-pad-added", self.__src_pad_added_cb)
from gst import element_factory_make, STATE_PLAYING
src = element_factory_make("autoaudiosrc")
self.__pipeline.add(src)
srcpad = stream.get_property ("sink-pad")
src.get_pad("src").link(srcpad)
from gi.repository.GObject import idle_add
idle_add(src.set_state, STATE_PLAYING)
return False


This fixed it for me.

>>
>>                print "End of stream created!"
>>                return False
>>
>>        def __src_pad_added_cb(self, stream, pad, codec):
>>                print "Start of __src_pad_added_cb"
>>                from gst import STATE_PLAYING, parse_bin_from_description
>>                sink = parse_bin_from_description("audioconvert !
>> audioresample !
>> audioconvert ! autoaudiosink", True)
>>                pad.link(sink.get_pad("sink"))
>>                sink.set_state(STATE_PLAYING)
>>                self.__pipeline.add(sink)
>
> Same problem here.
>
>>
>>                print "End of __src_pad_added_cb"
>>                return False
>>
>>        def __session_created_cb(self, channel, conference, participant):
>>                print "Start of __session_created_cb"
>>                self.__pipeline.add(conference)
>>                from gst import STATE_PLAYING
>>                self.__pipeline.set_state(STATE_PLAYING)
>>                print "End of __session_created_cb"
>>                return False
>>

I think calling the states in an idle handler also helps, but I didn't
need to do
that in the pad added callback.

Thanks for your help.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] gst.LinkError in Telepathy Farsight

[Mystilleef]

I'm getting the following error with tp-farsight

=
Traceback (most recent call last):
  File "/home/lateef/teletest/MediaChannelStreamer.py", line 54, in
__stream_created_cb
src.get_pad("src").link(srcpad)
gst.LinkError: 
=

The code in question:


def __stream_created_cb(self, channel, stream):
print "Start of stream created!"
stream.connect("src-pad-added", self.__src_pad_added_cb)
srcpad = stream.get_property ("sink-pad")
from gst import element_factory_make, STATE_PLAYING
src = element_factory_make("audiotestsrc")
src.get_pad("src").link(srcpad)
src.set_property("is-live", True)
src.set_state(STATE_PLAYING)
self.__pipeline.add(src)
print "End of stream created!"
return False

def __src_pad_added_cb(self, stream, pad, codec):
print "Start of __src_pad_added_cb"
from gst import STATE_PLAYING, parse_bin_from_description
sink = parse_bin_from_description("audioconvert ! audioresample 
!
audioconvert ! autoaudiosink", True)
pad.link(sink.get_pad("sink"))
sink.set_state(STATE_PLAYING)
self.__pipeline.add(sink)
print "End of __src_pad_added_cb"
return False

def __session_created_cb(self, channel, conference, participant):
print "Start of __session_created_cb"
self.__pipeline.add(conference)
from gst import STATE_PLAYING
self.__pipeline.set_state(STATE_PLAYING)
print "End of __session_created_cb"
return False



I'm not a Gstreamer expert so I appreciate any help.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Type Conversion Error in PyGI tp-glib

[Mystilleef]

On Tue, Jun 14, 2011 at 2:52 AM, Tomeu Vizoso  wrote:
> On Mon, Jun 13, 2011 at 16:04, Danielle Madeley
>  wrote:
>> On Mon, 2011-06-13 at 15:23 +0200, Tomeu Vizoso wrote:
>>
>>> > I'm I doing something wrong? Or is this a bug?
>>>
>>> PyGObject is auto-converting your Python int into a GValue, but isn't
>>> choosing the type that the C side expects. What i think should be done
>>> in this case (other than moving tp-glib from dbus-glib to gdbus) is to
>>> give PyGObject a hint of what type should the GValue map to, something
>>> like:
>>>
>>>         "keepalive-interval": GValue(60, GValue.UInt32),
>>>
>>> Unfortunately, I don't think that exists, but would be worth asking to
>>> the PyGObject community and checking if a ticket already exists in
>>> bugzilla.gnome.org.
>>
>> Tomeu is right, this is actually the bug. I was mistakenly confused with
>> dbus-python.
>>
>> Tomeu, out of interest would PyGObject handle this better if it was a
>> GVariant. Now that gjs has gained GVariant support, I think we should
>> start exposing GVariant-based APIs for gobject-introspection instead of
>> TpAsv-based ones.
>
> Yup, with variants, PyGObject doesn't try any more to guess the type
> that the C side wants, so the user needs to do:
>
> GLib.Variant('i', 42)
> GLib.Variant('u', 42)
>
> Regards,
>
> Tomeu
>

John P says telepathy-glib should use overrides to avoid this problem.

His comment is here. https://bugzilla.gnome.org/show_bug.cgi?id=652518#c1

The solution he provided in the comments also solves the problem for me.

from gi.repository import GObject
value = GObject.Value()
value.init(GObject.TYPE_UINT)
value.set_uint(60)

Then pass value as a guint parameter.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] How do I use Interfaces from PyGI tp-glib

[Mystilleef]

I may have run into a problem where some of the methods and
signals in certain interfaces are not exposed in PyGI tp-
glib.

For example, some of the methods and all of the signals in
oft.Channel.Interface.Group are not exposed in PyGI tp-glib.

In particular, I'm trying to add a member to a channel to
start an incoming SIP call. I've prepared the channel with
all the required features (including FEATURES GROUP). So
the channel is READY and PREPARED. However, the channel
object doesn't have an add_member method.

How do I get methods and signals for Interfaces in PyGI
tp-glib?

Thanks
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] How do I receive channels in an observer client?

[Mystilleef]

On Tue, Jun 14, 2011 at 10:31 AM, Simon McVittie
 wrote:
> On Tue, 14 Jun 2011 at 10:11:06 -0400, Mystilleef wrote:
>> Yet, I can't receive any media channels.
> ...
>> I have _neither_ an approver or handler client implemented
>> yet. Does this matter?
>
> I don't know exactly what you mean by "can't receive", but if you mean "my
> contacts see me as not callable and/or can't call me" and you're on XMPP,
> that may be because it's the Handler that tells Gabble which NAT traversal
> mechanisms it understands. Without a Handler, Gabble is aware that it doesn't
> support any NAT traversal mechanisms, and tells your contacts that it doesn't
> support any; your contacts interpret that as "can't be called".
>

I meant receiving incoming SIP calls.

> Another possibility is this MC bug:
> <https://bugs.freedesktop.org/show_bug.cgi?id=29022>
> in which channels for which you don't have a Handler aren't given to Observers
> either, on the basis that MC is about to close the channel anyway. I think
> that's a bug - it should tell the Observers, wait for them all to respond,
> *then* close the channel - but the patches to fix it haven't been merged yet.
>

Aha! Most likely the same problem I'm having.

>> P.S. The only time I can receive media channels is when I
>> have Empathy running.
>
> While it's running, Empathy provides a StreamedMedia Handler.
>
> You're not going to be usefully callable unless you have some sort of Handler
> for the channel, so if you don't want to use the one from Empathy, you'll
> have to implement another. As a "quick hack" first implementation, it could
> just accept the channel and not do anything with it...
>

Thanks a lot.  I'll implement a handler.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] How do I receive channels in an observer client?

[Mystilleef]

I think I'm missing a step to help my observer receive
incoming media channels.

Here's what I've done.

1) I've registered an Account with the AccountManager

2) Via the Account I've requested the presence to be Available.
If I'm not mistaken this automatically sets up a connection.

3) I've initialized a simple observer client and registered
it with the AccountManager and it has a name on the bus.

Code for the observer client: http://pastebin.com/zvEc8HeK

Yet, I can't receive any media channels.

P.S. The only time I can receive media channels is when I
have Empathy running.

What step am I missing? Do I need to initialize and prepare
a ChannelDispatcher?

I have _neither_ an approver or handler client implemented
yet. Does this matter?

Thanks
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Type Conversion Error in PyGI tp-glib

[Mystilleef]

On Mon, Jun 13, 2011 at 9:23 AM, Tomeu Vizoso  wrote:
> On Sun, Jun 12, 2011 at 09:12, Mystilleef  wrote:
>> I get the following error when I use an integer parameter
>> during account creation:
>>
>> Traceback (most recent call last):
>>  File "/home/lateef/teletest/AccountCreator.py", line 75, in 
>> __create_async_cb
>>    account = telepathy_account_manager.create_account_finish(result)
>>  File "/usr/lib/python2.7/site-packages/gi/types.py", line 44, in function
>>    return info.invoke(*args)
>> glib.GError: 
>> org.freedesktop.DBus.GLib.UnmappedError.McdAccountManagerError.Code0:
>> Failed to set parameter: parameter keepalive-interval must be of type
>> guint, not gint
>>
>> Python only uses ints, no uints. And I can't find a way to
>> convert from Python ints to Glib uints.
>>
>> I'm I doing something wrong? Or is this a bug?
>
> PyGObject is auto-converting your Python int into a GValue, but isn't
> choosing the type that the C side expects. What i think should be done
> in this case (other than moving tp-glib from dbus-glib to gdbus) is to
> give PyGObject a hint of what type should the GValue map to, something
> like:
>
>        "keepalive-interval": GValue(60, GValue.UInt32),
>
> Unfortunately, I don't think that exists, but would be worth asking to
> the PyGObject community and checking if a ticket already exists in
> bugzilla.gnome.org.
>

I filed a bug report.

https://bugzilla.gnome.org/show_bug.cgi?id=652518

Is there anything tp-glib can do to help with the type conversion?
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Type Conversion Error in PyGI tp-glib

[Mystilleef]

On Mon, Jun 13, 2011 at 7:27 AM, Danielle Madeley
 wrote:
> Paste the code somewhere?
>
> On Mon, 2011-06-13 at 07:03 -0400, Mystilleef wrote:
>> On Mon, Jun 13, 2011 at 5:04 AM, Danielle Madeley
>>  wrote:
>> > On Sun, 2011-06-12 at 03:12 -0400, Mystilleef wrote:
>> >> I get the following error when I use an integer parameter
>> >> during account creation:
>> >>
>> >> Traceback (most recent call last):
>> >>   File "/home/lateef/teletest/AccountCreator.py", line 75, in 
>> >> __create_async_cb
>> >>     account = telepathy_account_manager.create_account_finish(result)
>> >>   File "/usr/lib/python2.7/site-packages/gi/types.py", line 44, in 
>> >> function
>> >>     return info.invoke(*args)
>> >> glib.GError: 
>> >> org.freedesktop.DBus.GLib.UnmappedError.McdAccountManagerError.Code0:
>> >> Failed to set parameter: parameter keepalive-interval must be of type
>> >> guint, not gint
>> >>
>> >> Python only uses ints, no uints. And I can't find a way to
>> >> convert from Python ints to Glib uints.
>> >>
>> >> I'm I doing something wrong? Or is this a bug?
>> >
>> > Use the constructors in dbus.types. e.g. dbus.UInt32
>> > http://dbus.freedesktop.org/doc/dbus-python/api/dbus.types-module.html
>

Code is here.

http://pastebin.com/CJ4FUA0B

It creates an SIP Account. You have to provide an ACCOUNT
and PASSWORD. See lines 5 and 6.

On line 65 when I use PARAMETERS_BUGGY I get the following
error:


Initialized telepathy account manager
telepathy account manager is prepared

** (process:6253): WARNING **: Cannot marshal type "PyObject" in variant
**
ERROR:dbus-gproxy.c:2179:dbus_g_proxy_marshal_args_to_message: code
should not be reached


This error is a little different from the one I posted
earlier. Still trying to figure out why.

If you change PARAMETERS_BUGGY to PARAMETERS on line 65,
it should create the account without any errors.

Although this new error doesn't provide any clues as to what
the problem is, the first error I posted earlier suggests it
might be a type conversion problem in the "keepalive-
interval" value in the parameters. I'm re-posting the first
error I was getting.


Traceback (most recent call last):
 File "/home/lateef/teletest/AccountCreator.py", line 75, in __create_async_cb
   account = telepathy_account_manager.create_account_finish(result)
 File "/usr/lib/python2.7/site-packages/gi/types.py", line 44, in function
   return info.invoke(*args)
glib.GError: 
org.freedesktop.DBus.GLib.UnmappedError.McdAccountManagerError.Code0:
Failed to set parameter: parameter keepalive-interval must be of type
guint, not gint

___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Type Conversion Error in PyGI tp-glib

[Mystilleef]

On Mon, Jun 13, 2011 at 5:04 AM, Danielle Madeley
 wrote:
> On Sun, 2011-06-12 at 03:12 -0400, Mystilleef wrote:
>> I get the following error when I use an integer parameter
>> during account creation:
>>
>> Traceback (most recent call last):
>>   File "/home/lateef/teletest/AccountCreator.py", line 75, in 
>> __create_async_cb
>>     account = telepathy_account_manager.create_account_finish(result)
>>   File "/usr/lib/python2.7/site-packages/gi/types.py", line 44, in function
>>     return info.invoke(*args)
>> glib.GError: 
>> org.freedesktop.DBus.GLib.UnmappedError.McdAccountManagerError.Code0:
>> Failed to set parameter: parameter keepalive-interval must be of type
>> guint, not gint
>>
>> Python only uses ints, no uints. And I can't find a way to
>> convert from Python ints to Glib uints.
>>
>> I'm I doing something wrong? Or is this a bug?
>
> Use the constructors in dbus.types. e.g. dbus.UInt32
> http://dbus.freedesktop.org/doc/dbus-python/api/dbus.types-module.html
>

Thanks for your response. I did. It didn't work.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] Type Conversion Error in PyGI tp-glib

[Mystilleef]

I get the following error when I use an integer parameter
during account creation:

Traceback (most recent call last):
  File "/home/lateef/teletest/AccountCreator.py", line 75, in __create_async_cb
account = telepathy_account_manager.create_account_finish(result)
  File "/usr/lib/python2.7/site-packages/gi/types.py", line 44, in function
return info.invoke(*args)
glib.GError: 
org.freedesktop.DBus.GLib.UnmappedError.McdAccountManagerError.Code0:
Failed to set parameter: parameter keepalive-interval must be of type
guint, not gint

Python only uses ints, no uints. And I can't find a way to
convert from Python ints to Glib uints.

I'm I doing something wrong? Or is this a bug?
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Location of FEATURE constants in PyGI tp-glib?

[Mystilleef]

On Sat, Jun 11, 2011 at 5:57 PM, Xavier Claessens  wrote:
> Le samedi 11 juin 2011 à 17:42 -0400, Mystilleef a écrit :
>> Hi,
>>
>> Where are the FEATURE constants (e.g TP_ACCOUNT_MANAGER_FEATURE_CORE)
>> located in PyGI tp-glib?
>
> Macros are not imported in the g-i, sadly. So you need to call the
> function that returns the feature quark:
>
> TelepathyGLib.AccountManager.get_feature_quark_core()
>

Thanks Xavier!

I don't know how I overlooked that method.

Thanks
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

[Telepathy] Location of FEATURE constants in PyGI tp-glib?

[Mystilleef]

Hi,

Where are the FEATURE constants (e.g TP_ACCOUNT_MANAGER_FEATURE_CORE)
located in PyGI tp-glib?

I need to pass a FEATURE constant as an argument to the
"is_prepared" method in TP proxy objects.
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Status of Telepathy Python

[Mystilleef]

On Tue, Jun 7, 2011 at 1:24 AM, Jiri Baum  wrote:
> Hello,
>
> Mystilleef:
>> Also are there any Free Software Python apps that have been written with
>> Telepathy?
>
> I've made a start on one, but have been rather neglecting it for the last year
> or so...  However, the Telepathy Tube aspect is fairly functional — it works,
> but many less common situations are not handled. Feel free to copy stuff!
>
> http://www.baum.com.au/connectr
>
>> I'd be more qualified to contribute when I know what I'm doing. Newbies like
>> myself shouldn't be anywhere near the docs or examples. :-)
>
> Heh, where do you think the "DTube tutorial" on the wiki came from... Like
> you, I couldn't find any documentation aimed at app writers, so as I figured
> it out, I wrote it up as a tutorial. Somebody else even edited the code since
> (though not the tutorial), but I can't find a "history" button on the wiki so
> I can't see what was changed since I last touched it.
>
>
> Jiri

Thanks Jiri! That's exactly what I need. Thank you!
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy

Re: [Telepathy] Status of Telepathy Python

[Mystilleef]

Danielle thanks for the response.

On Mon, Jun 6, 2011 at 10:14 PM, Danielle Madeley
 wrote:
> On Mon, 2011-06-06 at 21:26 -0400, Mystilleef wrote:
>
>> I don't understand why though. I thought Telepathy was just
>> a DBus API. So maintaining the Python bindings against the
>> the DBus API doesn't sound too complicated. Afterall, all
>> we're doing is just calling DBus APIs in Python. I'm I
>> missing something?
>
> We actually want to move people away from direct use of the D-Bus API
> and towards using high-level, easier, useful API that calls the D-Bus
> API for you.
>

I see. I don't mind using the DBus APIs as long as I know what I'm doing.

>> > The future of writing Telepathy in Python is likely tp-glib via
>> > gobject-introspection/PyGI. This is how gnome-shell does it's Telepathy
>> > integration in Javascript. I don't know that anyone has tried writing a
>> > Python client in it today, but someone has to go first.
>>
>> I don't mind going first if I'm nudged in the right
>> direction. Are there any example code? Can I write a full
>> blown SIP client using tp-glib via PYGI today? Are there
>> any limitations?
>
> There isn't example code doing this in Python yet. You'd need to use a
> combination of the javascript code in gnome-shell, the telepathy-glib
> examples + any notes that exist on how PyGI generates API. People on
> #telepathy (irc.freenode.net) would gladly give you assistance here;
> it's our goal that this works, but no one has any time to work on it at
> the moment.
>
> There may be limitations, bugs that need fixing. Again, we haven't ever
> actually tested this, besides some very initial work I did a long time
> ago.
>
> You may end up having to make fixes to the introspection annotation in
> tp-glib, and find that pieces of high-level API you need are missing.
> OTOH, you _should_ be able to write a client at least as complete as
> gnome-shell.
>

I'll look into this. However, I'm nervous about writing an application using
Gobject Introspection. I've written a small app using it, but I'm not sure,
I'd use it for a big application, yet.



>> I don't want to be completely negative. So I'll add I was
>> able to figure out some stuff using the DBus Spec and the
>> developer's handbook which does a fantastic job explaining
>> the architecture of Telepathy and would be even better
>> if the current examples (the Python ones in particular) are
>> updated and perhaps even more added.
>
> I happily welcome contributed/updated examples. Unfortunately I don't
> have any time to really invest in the docs at the moment.
>

I'd be more qualified to contribute when I _know_ what I'm doing. Newbies like
myself shouldn't be anywhere near the docs or examples. :-)

>> >> https://bugs.freedesktop.org/show_bug.cgi?id=35314
>> >
>> > This bug is a mistake in how someone is using the API, not a mistake in
>> > tp-python.
>>
>> What is the right way to use that API?
>
> Telepathy is meant to be used entirely asynchronously. You need to ready
> the object.

What object do I need to ready? Dbus Proxy objects, AccountManager, Account,
Connection objects? Or all of the above?

> Pass the keyword-arg ready_handler with the name of a
> callback for when the object is ready. [Notice also here the
> asynchronous method call.]
>
> For instance:
>
>        def main():
>            account = telepathy.client.Account(
>                '/org/freedesktop/Telepathy/Account/' + sys.argv[1],
>                ready_handler=_account_ready,
>                error_handler=_error)
>
>            loop = gobject.MainLoop()
>            loop.run()
>
>        def _account_ready(account):
>            # get the connection
>            account[dbus.PROPERTIES_IFACE].Get(ACCOUNT, 'Connection',
>                reply_handler=lambda x: _got_connection_path(account,
>        x),
>                error_handler=_error)
>
> In the tp-glib API this is called "preparing" an object. It does things
> like requesting the core properties, such as what interfaces are
> available on the object.
>

Thanks for the example, I'll look more into it.

>> After establishing a connection I can't use the
>> CONNECTION_INTERFACE_REQUESTS DBus interface at all.
>>
>> connection[CONNECTION_INTERFACE_REQUESTS] always raises an
>> error. I'm I not supposed to call that interface?
>
> Well, ideally you should make your requests to the ChannelDispatcher,
> which will forward them to the appropriate Co

Re: [Telepathy] Status of Telepathy Python

[Mystilleef]

Thanks for your response Danielle. I appreciate it.

On Mon, Jun 6, 2011 at 7:17 PM, Danielle Madeley
 wrote:
> Telepathy-Python is mostly unmaintained; especially the client-side APIs
> (where let's face it, there aren't many, nothing high-level, and even
> some of the low-level classes are missing).
>

I don't understand why though. I thought Telepathy was just
a DBus API. So maintaining the Python bindings against the
the DBus API doesn't sound too complicated. Afterall, all
we're doing is just calling DBus APIs in Python. I'm I
missing something?

> The future of writing Telepathy in Python is likely tp-glib via
> gobject-introspection/PyGI. This is how gnome-shell does it's Telepathy
> integration in Javascript. I don't know that anyone has tried writing a
> Python client in it today, but someone has to go first.
>

I don't mind going first if I'm nudged in the right
direction. Are there any example code? Can I write a full
blown SIP client using tp-glib via PYGI today? Are there
any limitations?

> As the author of a lot of the documentation, I know it needs a lot of
> work. It doesn't document today's best practice, it's strangely
> organised with way too much cross-referencing, and doesn't dealt well
> with documenting the different approaches taken by APIs (also it has 0
> Qt4 documentation).
>
> It is my plan (who knows when) to convert the documentation into
> something topic based (i.e. Mallard) which should allow for much easier
> expansion. Including 'cook book' style examples like you're wanting.
>
> I still think explaining the architecture is important. Lots of people
> fail to understand the architecture of Telepathy, and as a result make
> assumptions, and thus mistakes, when writing their clients.
>

I agree explaining architecture is very important. It's what
drew me to telepathy. However, architecture does no good
when you can't figure out how to use the API. Just the same
way theoretical knowledge is no good without practical
experience. Case in point, the new architecture recommends
you use Account Manager/Accounts and Channel Dispatchers to
manage connections. However, All the example code I read
seem to be using connection managers directly to do this.
The docs don't show "how" to do this either. So there's very
good explanation, but at this point the explanation is
not useful if I don't know how to put it into practice. I
know I'd eventually figure it out if I play long enough with
it or read some source code, but I think the experience
could be improved. When it comes to documentation "how",
"why" and "when" is a lot more important than "what".

I don't want to be completely negative. So I'll add I was
able to figure out some stuff using the DBus Spec and the
developer's handbook which does a fantastic job explaining
the architecture of Telepathy and would be even better
if the current examples (the Python ones in particular) are
updated and perhaps even more added.


> On Mon, 2011-06-06 at 11:44 -0400, Mystilleef wrote:
>
>> Apart from the documentation problems (documentation should
>> emphasize "how" to do things as opposed to explaining
>> architectural designs and contain plenty examples), it
>> seems as if some interfaces available in the documentation
>> don't even work. See this bug for example.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=35314
>
> This bug is a mistake in how someone is using the API, not a mistake in
> tp-python.
>

What is the right way to use that API?

After establishing a connection I can't use the
CONNECTION_INTERFACE_REQUESTS DBus interface at all.

connection[CONNECTION_INTERFACE_REQUESTS] always raises an
error. I'm I not supposed to call that interface?

>> QT does a fantastic job with their documentation it can be a
>> source of inspiration for the Telepathy framework.
>
> Have you considered Telepathy-Qt4?
>

5 years ago, I would have jumped at Telepathy-glib or
Telepathy-QT4. However, my days of writing desktop clients
in such languages (C/C++) is over. This is why I'm surprised
the Python bindings for Telepathy gets the least love. GIT
tells me the Python telepathy module has not seen any
commits in 5 months. I'm finding it hard to believe
developers today would choose Glib and Qt4 bindings over
Python. I'm I missing something? The situation seems to be
the reverse in most frameworks I've used.

>> Anyway, back to Telepathy Python. Is it still maintained? Is
>> it wise for us to use it to build an SIP client or should I
>> look elsewhere? Also are there any Free Software Python
>> apps that have been written with Telepathy?
>
> 

[Telepathy] Status of Telepathy Python

[Mystilleef]

My decision to use Telepathy (Python) to write an SIP client
is on shaky grounds.

I'm running into snag after snag and it's affecting my
confidence in using this framework for my project.

Apart from the documentation problems (documentation should
emphasize "how" to do things as opposed to explaining
architectural designs and contain plenty examples), it
seems as if some interfaces available in the documentation
don't even work. See this bug for example.

https://bugs.freedesktop.org/show_bug.cgi?id=35314

That bug was submitted 3 months ago and there has been no
response, triage or confirmation of the bug from any
developer. The bug is most likely a blocker on any Python
project that wants to use Telepathy.

This bug might also be of interest for whoever
maintains telepathy farstream.

https://bugs.freedesktop.org/show_bug.cgi?id=37941

The Python examples in the Developer's handbook use
deprecated APIs which will inevitably confuse users new to
the framework. To make matters worse, most of the Python
examples don't even work.

On the documentation, the emphasize should be on "how" to
use an API. Each API should be accompanied with several
examples specifying several use cases.Users should be able
to read an API doc and know what it does, how, and when to
use it. Unfortunately, that's not the case with Telepathy. I
have to bounce from example code that I don't trust to work,
to reading source code, to reading the spec, to trial and
error hacking. Thus making my progress with framework very
slow.

QT does a fantastic job with their documentation it can be a
source of inspiration for the Telepathy framework.

Anyway, back to Telepathy Python. Is it still maintained? Is
it wise for us to use it to build an SIP client or should I
look elsewhere? Also are there any Free Software Python
apps that have been written with Telepathy?

Thanks
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy