Re: [Telepathy] Mission Control's crash handling by other Telepathy components
So telepathy-mission-control 5.12.1 fixes the common crashes, so some of what I said here no longer applies, so sorry for the big email. Anyway, to prevent me from writing a long text again for nothing, allow me to ask: a) what happens when MC is killed and someone initiates a new chat with me? b) what happens when MC is killed and someone continues a chat with me? It appeared to me the messages are delivered to me on b) but not on a) ? -- Pedro ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Mission Control crash "pattern"
On Mon, Jul 16, 2012 at 8:07 PM, Pedro Francisco wrote: > I can crash Mission Control following a certain pattern, namely: > (...) Oops! Crash seems to be fixed on telepathy-mission-control 5.12.1 :) Sorry for the noise! -- Pedro ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Mission Control crash "pattern"
I can crash Mission Control following a certain pattern, namely: start: 1) enable all accounts (in my case, Facebook via GOA, MSN via Haze and GTalk via GOA) 2) repeat enable "People Nearby Account", wait, disable "People Nearby Account" (or you can try "while [ 1 ]; do mc-tool enable salut/local_xmpp/account1; sleep 1; mc-tool disable salut/local_xmpp/account1; done") 3) If after 2 minutes or so nothing happens, give up for ten minutes, try again later. 4) If even so nothing happens then it's because Mission Control is 'stable' and it won't crash. Try killall /usr/libexec/mission-control-5; /usr/libexec/mission-control-5 , wait for it to stabilize and then repeat from start. I got as stderr of MC_DEBUG=all /usr/libexec/mission-control-5 : process 30916: arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_check_is_valid_utf8 (*string_p)" failed in file dbus-message.c line 2526. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted (core dumped) So, in order to get a better backtrace, I compiled dbus with "-rdynamic" (actually on ./configure it's called, "--enable-asserts") . I got something like "*** glibc detected *** /usr/libexec/mission-control-5: malloc(): smallbin double linked list corrupted: 0x08a5b3f0 ***", "*** glibc detected *** /usr/libexec/mission-control-5: corrupted double-linked list: 0x084e1030 *** and "arguments to dbus_message_iter_append_basic() were incorrect, assertion "_dbus_check_is_valid_utf8 (*string_p)" failed in file dbus-message.c line 2526" (note: I don't understand how dbus and MC's malloc are related...) Those logs are available at https://bugzilla.redhat.com/attachment.cgi?id=598513 , https://bugzilla.redhat.com/attachment.cgi?id=598514 and https://bugzilla.redhat.com/attachment.cgi?id=598515 respectively (Fedora's bug report is https://bugzilla.redhat.com/show_bug.cgi?id=827083 ). I hope the information above is of use :) I'll check this ML every few days in order to give more information if required. -- Pedro ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Mission Control's crash handling by other Telepathy components
Hello! This was verified on Empathy 3.4.2.3 . I'll detail some caveats with the current handling of Mission Control's crash by other Telepathy components. User-side description (Empathy window is open and visible): 1) Mission Control crashes 2) Empathy continues to show people online 3) people talking to user do NOT trigger respawn of Mission Control 4) interface shows user online, others see him online, but the user does not receive message from others (and he gets offline once he tries to speak to others, I think) Workarounds: various ways to respawn Mission Control: * /usr/libexec/mission-control-5 (best) * setting a different status in Empathy (MC seems to get in an inconsistent state, will crash again 'soon', some accounts will not connect, etc.) * killall /usr/bin/empathy; empathy (closing the window will not work, I think; only using Chat > Quit; I'm unaware if this triggers a unstable Mission Control being spawned) Issues here: * messages are not received by the user after MC crash * user interface deceives the user into thinking all is well * even after spawning a new Mission Control (via changing status in an already opened Empathy window), the probability of Mission Control crashing is higher, as said above (I don't know why; should be the same if launched via D-Bus activation or via command-line, no?) * every Empathy/Mission Control crash interaction freezes the desktop (I'm assuming due to the high amount of D-Bus messages exchanged, so a simple crash freezes whole desktop for a 1 or 2 seconds, one or two times per crash) * when Mission Control is run manually (e.g., script, user typing on the console /usr/libexec/mission-control-5) the connection for all accounts will be set to offline status unless "mc-tool autoconnect ACCOUNT_ID on" has been run before. I hope the above analysis is of use :) -- Pedro ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] "Reset" Empathy state (not confs)
On Mon, Jul 16, 2012 at 4:02 PM, Nicolas Dufresne wrote: > Le samedi 14 juillet 2012 à 12:24 +0100, Pedro Francisco a écrit : >> I've found out this last line is the most important, otherwise it'd >> seem some accounts wouldn't be able to work properly; I'm guessing >> multiple MC would be spawned and something would be only >> half-working. > > This is not possible because D-Bus won't let a second Mission Control > instance own the same name. Ok, that makes sense. Further investigation reveals the problem is some kind of inconsistent state of Mission Control after it crashes and is subsequently spawned. I'll report later on this ML. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: Empathy 3.5.4
Empathy 3.5.4 is now available for download from: http://download.gnome.org/sources/empathy/3.5/ c2581afd2600d362ec52ee1d1d22e38c empathy-3.5.4.tar.xz What is it? === Empathy is a messaging program which supports text, voice, and video chat and file transfers over many different protocols. Empathy is the default chat client in GNOME, and is based on the Telepathy framework, making it easier for other GNOME applications to integrate collaboration functionality. You can visit the project web site: http://live.gnome.org/Empathy What's New? === Legacy chat themes from Gossip have been removed and re-implemented using the Adium theme format. Dependencies: • GLib ≥ 2.33.3 • telepathy-glib ≥ 0.19.3 Bugs fixed: - Fixed #645921, Drop old chat themes and make Adium theme mandatory (Danielle Madeley) - Fixed #627948, Avatar option for irc superfous (Will Thompson) - Fixed #678331, Sending a file from the conversation window silently fails (Guillaume Desmottes) - Fixed #678524, [new roster] Re-Implement sending files using DnD (Guillaume Desmottes) - Fixed #678807, empathy-chat crashed with SIGSEGV in _tp_base_client_handle_channels() (Guillaume Desmottes) - Fixed #678845, Strip %senderPrefix% in Adium themes (Will Thompson) - Fixed #678875, empathy-nautilus-sendto should use RosterView (Laurent Contzen) - Fixed #679136, Stop using EmpathyContactWidget in the subscription request dialog (Guillaume Desmottes) - Fixed #679255, Remove EmpathyChatView (Guillaume Desmottes) - Fixed #679332, Handle Adium themes that use .AdiumMessagestyle (Guillaume Desmottes) - Fixed #679396, Bind keyboard keys on DTMF events (Guillaume Desmottes) - Fixed #679532, Contact names not aligned (Guillaume Desmottes) Translations: - Updated be Translation (Ihar Hrachyshka) - Updated el Translation (Tom Tryfonidis) - Updated es Translation (Daniel Mustieles) - Updated he Translation (Yaron Shahrabani) - Updated lt Translation (Žygimantas Beručka) - Updated nb Translation (Kjartan Maraas) - Updated pa Translation (A S Alam) - Updated zh_HK Translation (Cheng-Chia Tseng) - Updated zh_TW Translation (Cheng-Chia Tseng) Documentation translations: - Updated el Documentation translation (Tom Tryfonidis) 16 July 2012 Empathy team ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] "Reset" Empathy state (not confs)
Le samedi 14 juillet 2012 à 12:24 +0100, Pedro Francisco a écrit : > I've found out this last line is the most important, otherwise it'd > seem some accounts wouldn't be able to work properly; I'm guessing > multiple MC would be spawned and something would be only > half-working. This is not possible because D-Bus won't let a second Mission Control instance own the same name. cheers, Nicolas ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] GNOME/KDE: standarisation of secret schemas
2012/7/16 Debarshi Ray : >> What I am missing here is how all this blends with >> gnome-online-accounts and the future kde web-accounts kcm. I'm not >> sure how GOA works > > GOA is a single sign-on mechanism. When you add a new account in GOA, what it > does is verify the credentials supplied by the user and stores it in > gnome-keyring via libsecret. The credentials can be a OAuth 1 or OAuth 2 > token, > a password, etc.. > > Applications can then query GOA and get a list of configured accounts, the > credentials, and features provided by the account (eg., mail, contacts, etc.). > GOA can also supply some configuration related to the account. eg., for a > Google account it provides the IMAP and SMTP details which are needed to set > up a GMail account. That way an application (eg., Evolution) can auto > configure itself. This is pretty much what webaccounts in KDE does. I'm CC'ing the maintainer in this discussion, probably it might be worth researching this outside the Telepathy area and in a broader perspective, as George suggested. > > Happy hacking, > Debarshi > > -- > Slacktivism: the idea that 'sharing', 'liking' or retweeting will solve a > problem. > ___ > 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] GNOME/KDE: standarisation of secret schemas
> What I am missing here is how all this blends with > gnome-online-accounts and the future kde web-accounts kcm. I'm not > sure how GOA works GOA is a single sign-on mechanism. When you add a new account in GOA, what it does is verify the credentials supplied by the user and stores it in gnome-keyring via libsecret. The credentials can be a OAuth 1 or OAuth 2 token, a password, etc.. Applications can then query GOA and get a list of configured accounts, the credentials, and features provided by the account (eg., mail, contacts, etc.). GOA can also supply some configuration related to the account. eg., for a Google account it provides the IMAP and SMTP details which are needed to set up a GMail account. That way an application (eg., Evolution) can auto configure itself. Happy hacking, Debarshi -- Slacktivism: the idea that 'sharing', 'liking' or retweeting will solve a problem. pgp0g3VI2pi2n.pgp Description: PGP signature ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] GNOME/KDE: standarisation of secret schemas
On Mon, Jul 16, 2012 at 1:16 PM, Guillaume Desmottes
wrote:
> Hey,
>
> GNOME 3.6 is moving away [0] from gnome-keyring to libsecret.
> libsecret is a new client for the Secret Service DBus API. The Secret
> Service allows storage of passwords in a common way on the desktop.
> Supported by gnome-keyring and ksecretservice.
>
> Thanks to Stef we already have patch [1] porting Empathy to libsecret.
> This may be a good time to try to standardise the secret schemas used by
> Empathy and KDE-Telepathy for maximum synergy. Actually, maybe that's
> something we could add to the TP spec?
>
> Atm, Empathy stores and uses 2 secret keys:
>
> - CM param having the secret flag: (account-id, param-name)
> - The key of password protected rooms: (account-id, room-id)
>
> "account-id" is actually the account path, we way want to change it to a
> clearer name.
In kde-tp we store the account unique id ("cm/protocol/account")
mapped directly to the password. We don't save the param-name (not
needed, the auth channel doesn't ask for it) and we also don't save
passwords for rooms (I guess the only use case for that is irc, which
we don't support, right?).
>
> We'll have to define schema names for both keys. We could use something
> like "org.freedesktop.Telepathy.Account" and "
> org.freedesktop.Telepathy.Room".
>
>
> I have no idea how/if kde-tp is already using libsecret as well, so if
> you have some info please let me know.
>
KDE still uses KWallet, since KSecretService is apparently not working
correctly yet. Hopefully somebody will volunteer to fix it at some
point, but until then we are stuck with KWallet.
What I am missing here is how all this blends with
gnome-online-accounts and the future kde web-accounts kcm. I'm not
sure how GOA works, but in kde we plan to migrate to web-accounts when
it is ready, which means that all the authentication details will be
stored by web-accounts and the auth-handler will just use the
web-accounts API to make it interract with the CM. Therefore, we won't
need a telepathy-specific secrets storage.
Regards,
George
___
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] GNOME/KDE: standarisation of secret schemas
Hey, GNOME 3.6 is moving away [0] from gnome-keyring to libsecret. libsecret is a new client for the Secret Service DBus API. The Secret Service allows storage of passwords in a common way on the desktop. Supported by gnome-keyring and ksecretservice. Thanks to Stef we already have patch [1] porting Empathy to libsecret. This may be a good time to try to standardise the secret schemas used by Empathy and KDE-Telepathy for maximum synergy. Actually, maybe that's something we could add to the TP spec? Atm, Empathy stores and uses 2 secret keys: - CM param having the secret flag: (account-id, param-name) - The key of password protected rooms: (account-id, room-id) "account-id" is actually the account path, we way want to change it to a clearer name. We'll have to define schema names for both keys. We could use something like "org.freedesktop.Telepathy.Account" and " org.freedesktop.Telepathy.Room". I have no idea how/if kde-tp is already using libsecret as well, so if you have some info please let me know. G. [0] https://live.gnome.org/GnomeGoals/LibsecretMigration [1] https://bugzilla.gnome.org/show_bug.cgi?id=679884 ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
