telepathy-spec issueshttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues2019-12-09T11:23:02Zhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/178Telepathy CM's should allow a requested presence of type Unset, which is not ...2019-12-09T11:23:02ZBugzilla Migration UserTelepathy CM's should allow a requested presence of type Unset, which is not translated to current presence.## Submitted by James Smith
Assigned to **Telepathy bugs list**
**[Link to original bug (#100360)](https://bugs.freedesktop.org/show_bug.cgi?id=100360)**
## Description
This would be useful to unset saved account presences for exa...## Submitted by James Smith
Assigned to **Telepathy bugs list**
**[Link to original bug (#100360)](https://bugs.freedesktop.org/show_bug.cgi?id=100360)**
## Description
This would be useful to unset saved account presences for example, by listening for Unset presence type on the requestedPresenceChanged signal.https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/177Signal Protocol (Signal Messenger, formerly Axolotl / TextSecure) support for...2019-12-09T11:22:58ZBugzilla Migration UserSignal Protocol (Signal Messenger, formerly Axolotl / TextSecure) support for Telepathy## Submitted by Dennis Schridde
Assigned to **Telepathy bugs list**
**[Link to original bug (#94238)](https://bugs.freedesktop.org/show_bug.cgi?id=94238)**
## Description
It would be nice if Telepathy would support the Axolotl pro...## Submitted by Dennis Schridde
Assigned to **Telepathy bugs list**
**[Link to original bug (#94238)](https://bugs.freedesktop.org/show_bug.cgi?id=94238)**
## Description
It would be nice if Telepathy would support the Axolotl protocol (Signal messenger, formerly TextSecure).
There are currently three implementations, for Android, iOS and Google Chrome:
* https://github.com/WhisperSystems/Signal-Android
* https://github.com/WhisperSystems/Signal-iOS
* https://github.com/WhisperSystems/Signal-Desktop
An implementation of the underlying protocol is available via the libaxolotl-c library:
* https://github.com/WhisperSystems/libaxolotl-c
The Java library contains more documentation:
* https://github.com/whispersystems/libaxolotl-java
The wire protocol is described here:
* https://github.com/WhisperSystems/Signal-Android/wiki/ProtocolV2
And the specs are available here:
* https://github.com/trevp/axolotl/wikihttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/176Implement Matrix protocol support2019-12-09T11:22:54ZBugzilla Migration UserImplement Matrix protocol support## Submitted by Matthew Hodgson
Assigned to **Telepathy bugs list**
**[Link to original bug (#93556)](https://bugs.freedesktop.org/show_bug.cgi?id=93556)**
## Description
Matrix (Matrix.org) is a relatively new HTTP-based open sta...## Submitted by Matthew Hodgson
Assigned to **Telepathy bugs list**
**[Link to original bug (#93556)](https://bugs.freedesktop.org/show_bug.cgi?id=93556)**
## Description
Matrix (Matrix.org) is a relatively new HTTP-based open standard for decentralised group chat, VoIP, and freeform data pubsub with eventually consistent persistance semantics. The idea is to provide a very simple HTTP API to decentralise conversation data without any single server or service provider having a single point of control, whilst providing all the latest and greatest features you'd expect from a modern chat service like Slack, etc. Matrix also provides a wide range of bridges serverside for federating together existing services (IRC, Slack, Lync, XMPP etc) in a decentralised manner. The masterplan is to provide an open fabric for modern interoperable comms on the 'net with full decentralisation.
We implemented an experimental libpurple backend for Matrix (https://github.com/matrix-org/purple-matrix), but we just got a bug report from a telepathy user that it doesn't work via telepathy-haze, as haze assumes that all conversations are 1:1 whereas all conversations in Matrix are group chats (even if they only have 2 participants): https://github.com/matrix-org/purple-matrix/issues/1.
We don't have bandwidth to write a dedicated telepathy backend now (or fix haze), so I'm filing this bug in case someone in the telepathy community might be interested in playing with a fun new protocol and contributing one. Writing clients should be incredibly straightforward; the Matrix client-server API (in its simplest form) is just a REST API with long-polling to receive messages.
thanks!
### Depends on
* [Bug 23844](https://bugs.freedesktop.org/show_bug.cgi?id=23844)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/175make check fail in tests/dbus2019-12-09T11:22:52ZBugzilla Migration Usermake check fail in tests/dbus## Submitted by Kjartan Maraas `@kmaraas`
Assigned to **Telepathy bugs list**
**[Link to original bug (#92955)](https://bugs.freedesktop.org/show_bug.cgi?id=92955)**
## Description
Created attachment 119666
log file from testsuite...## Submitted by Kjartan Maraas `@kmaraas`
Assigned to **Telepathy bugs list**
**[Link to original bug (#92955)](https://bugs.freedesktop.org/show_bug.cgi?id=92955)**
## Description
Created attachment 119666
log file from testsuite
Attaching log file.
**Attachment 119666**, "log file from testsuite":
[test-suite.log](/uploads/46200895eb141e933281f68119bc5c9a/test-suite.log)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/174"top 5" CMs: unreviewed commits for 1.0 API catch-up2019-12-09T11:22:47ZBugzilla Migration User"top 5" CMs: unreviewed commits for 1.0 API catch-up## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#77200)](https://bugs.freedesktop.org/show_bug.cgi?id=77200)**
## Description
Code review is becoming a bottleneck, so Xavier has suggeste...## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#77200)](https://bugs.freedesktop.org/show_bug.cgi?id=77200)**
## Description
Code review is becoming a bottleneck, so Xavier has suggested that I merge "API catch-up" commits unreviewed and make a note of which ones they are.
Version: git masterhttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/173Add support for MTProto (Telegram)2020-06-14T20:51:50ZBugzilla Migration UserAdd support for MTProto (Telegram)## Submitted by Yajo
Assigned to **Telepathy bugs list**
**[Link to original bug (#75100)](https://bugs.freedesktop.org/show_bug.cgi?id=75100)**
## Description
It seems a good messaging service and protocol to be supported.
See h...## Submitted by Yajo
Assigned to **Telepathy bugs list**
**[Link to original bug (#75100)](https://bugs.freedesktop.org/show_bug.cgi?id=75100)**
## Description
It seems a good messaging service and protocol to be supported.
See https://telegram.org/source#telegram-java-librarieshttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/172Bring telepathy-ring up to 'core CM' status2019-12-09T11:22:41ZBugzilla Migration UserBring telepathy-ring up to 'core CM' status## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#70721)](https://bugs.freedesktop.org/show_bug.cgi?id=70721)**
## Description
telepathy-ring is currently living its own ...## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#70721)](https://bugs.freedesktop.org/show_bug.cgi?id=70721)**
## Description
telepathy-ring is currently living its own live on https://github.com/nemomobile/telepathy-ring
Ideally, it would be great to make it a core part of the Telepathy project which would include:
- Move its repo to git.freedesktop.org and create accounts for its current maintainers
- Move its bugs to bugs.freedesktop.org
- Add a test suite. I started working on this and already submit the simplest bits for review ( https://github.com/nemomobile/telepathy-ring/pull/14 ). I have more unfinished patches in https://github.com/gdesmott/telepathy-ring/commits/tests but they need more work (see my FIXME).
- Bump tp-blib deps to the latest pre 1.0 release and make sure we build with deprecations enabled
- Port to 1.0https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/171Telepathy 1.0 "would be nice" list2019-12-09T11:22:39ZBugzilla Migration UserTelepathy 1.0 "would be nice" list## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#68661)](https://bugs.freedesktop.org/show_bug.cgi?id=68661)**
## Description
Metabug for things that don't block Telepathy 1.0 but would ...## Submitted by Simon McVittie
Assigned to **Telepathy bugs list**
**[Link to original bug (#68661)](https://bugs.freedesktop.org/show_bug.cgi?id=68661)**
## Description
Metabug for things that don't block Telepathy 1.0 but would be nice to have.
Version: git master
### Depends on
* [Bug 68660](https://bugs.freedesktop.org/show_bug.cgi?id=68660)
* [Bug 14540](https://bugs.freedesktop.org/show_bug.cgi?id=14540)
* [Bug 25033](https://bugs.freedesktop.org/show_bug.cgi?id=25033)
* [Bug 46783](https://bugs.freedesktop.org/show_bug.cgi?id=46783)
* [Bug 55104](https://bugs.freedesktop.org/show_bug.cgi?id=55104)
* [Bug 70095](https://bugs.freedesktop.org/show_bug.cgi?id=70095)
* [Bug 77143](https://bugs.freedesktop.org/show_bug.cgi?id=77143)
* [Bug 77145](https://bugs.freedesktop.org/show_bug.cgi?id=77145)
* [Bug 77187](https://bugs.freedesktop.org/show_bug.cgi?id=77187)
* [Bug 77188](https://bugs.freedesktop.org/show_bug.cgi?id=77188)
* [Bug 77189](https://bugs.freedesktop.org/show_bug.cgi?id=77189)
* [Bug 77190](https://bugs.freedesktop.org/show_bug.cgi?id=77190)
* [Bug 77191](https://bugs.freedesktop.org/show_bug.cgi?id=77191)
* [Bug 77194](https://bugs.freedesktop.org/show_bug.cgi?id=77194)
* [Bug 77196](https://bugs.freedesktop.org/show_bug.cgi?id=77196)
* [Bug 77197](https://bugs.freedesktop.org/show_bug.cgi?id=77197)
* [Bug 77253](https://bugs.freedesktop.org/show_bug.cgi?id=77253)
* [Bug 77772](https://bugs.freedesktop.org/show_bug.cgi?id=77772)
* [Bug 77773](https://bugs.freedesktop.org/show_bug.cgi?id=77773)
* [Bug 77774](https://bugs.freedesktop.org/show_bug.cgi?id=77774)
* [Bug 78376](https://bugs.freedesktop.org/show_bug.cgi?id=78376)
* [Bug 78377](https://bugs.freedesktop.org/show_bug.cgi?id=78377)
* [Bug 78381](https://bugs.freedesktop.org/show_bug.cgi?id=78381)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/170Telepathy 1.0 (metabug)2019-12-09T11:22:37ZBugzilla Migration UserTelepathy 1.0 (metabug)## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#68660)](https://bugs.freedesktop.org/show_bug.cgi?id=68660)**
## Description
See Bug #23148 (spec) and Bug #31668 (partial implementation). We...## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#68660)](https://bugs.freedesktop.org/show_bug.cgi?id=68660)**
## Description
See Bug #23148 (spec) and Bug #31668 (partial implementation). We also need to block this with "port every significant CM", "port Empathy", "port misc services" (e.g. MC and the Logger), and ideally also "port tp-qt" (hopefully team KDE can help with that).
Version: git master
### Depends on
* [Bug 23148](https://bugs.freedesktop.org/show_bug.cgi?id=23148)
* [Bug 31668](https://bugs.freedesktop.org/show_bug.cgi?id=31668)
* [Bug 49737](https://bugs.freedesktop.org/show_bug.cgi?id=49737)
* [Bug 54879](https://bugs.freedesktop.org/show_bug.cgi?id=54879)
* [Bug 70991](https://bugs.freedesktop.org/show_bug.cgi?id=70991)
* [Bug 76369](https://bugs.freedesktop.org/show_bug.cgi?id=76369)
* [Bug 76685](https://bugs.freedesktop.org/show_bug.cgi?id=76685)
* [Bug 76855](https://bugs.freedesktop.org/show_bug.cgi?id=76855)
* [Bug 77029](https://bugs.freedesktop.org/show_bug.cgi?id=77029)
* [Bug 77030](https://bugs.freedesktop.org/show_bug.cgi?id=77030)
* [Bug 77882](https://bugs.freedesktop.org/show_bug.cgi?id=77882)
### Blocking
* [Bug 68661](https://bugs.freedesktop.org/show_bug.cgi?id=68661)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/169Implement PSYC (Protocol for Synchronous Conferencing) support2019-12-09T11:22:34ZBugzilla Migration UserImplement PSYC (Protocol for Synchronous Conferencing) support## Submitted by kxr..@..up.net
Assigned to **Telepathy bugs list**
**[Link to original bug (#66672)](https://bugs.freedesktop.org/show_bug.cgi?id=66672)**
## Description
PSYC is, as benchmarks show, the fastest yet extensible text...## Submitted by kxr..@..up.net
Assigned to **Telepathy bugs list**
**[Link to original bug (#66672)](https://bugs.freedesktop.org/show_bug.cgi?id=66672)**
## Description
PSYC is, as benchmarks show, the fastest yet extensible text-based protocol we are aware of, providing a messaging infrastructure for human conversation and social exchange of possibly binary data.
It has learned from protocols such as IRC and XMPP and chose an approach that should scale globally by generalizing the multicast concept beyond programmable chatrooms to presence awareness, event notification, news- and friendcasting. In commercial settings PSYC is also being used for telephony and audio/video.
PSYC provides trust metrics for a distributed social graph and publish/subscribe data. In combination with pseudonymous routing technology it turns into secure share, a platform for maximum privacy social networking and applications.https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/168telepathy gabble 0.17.3 fails on parallel build2019-12-09T11:22:29ZBugzilla Migration Usertelepathy gabble 0.17.3 fails on parallel build## Submitted by Dominique Leuenberger
Assigned to **Simon McVittie**
**[Link to original bug (#64285)](https://bugs.freedesktop.org/show_bug.cgi?id=64285)**
## Description
While building telepathy-gabble 0.17.3, there is a good ch...## Submitted by Dominique Leuenberger
Assigned to **Simon McVittie**
**[Link to original bug (#64285)](https://bugs.freedesktop.org/show_bug.cgi?id=64285)**
## Description
While building telepathy-gabble 0.17.3, there is a good chance that parallel build fails, with:
[ 64s] /usr/bin/python ../tools/xincludator.py \
[ 64s] all.xml > _gen/all.xml.tmp && mv _gen/all.xml.tmp _gen/all.xml
[ 64s] /usr/bin/python ../tools/c-constants-gen.py Gabble _gen/all.xml _gen/enums
[ 64s] /usr/bin/python ../tools/c-constants-gen.py Gabble _gen/all.xml _gen/enums
[ 64s] /usr/bin/python ../tools/glib-gtypes-generator.py \
[ 64s] _gen/all.xml _gen/gtypes Gabble
[ 64s] /usr/bin/python ../tools/glib-gtypes-generator.py \
[ 64s] _gen/all.xml _gen/gtypes Gabble
[ 64s] Traceback (most recent call last):
[ 64s] File "../tools/c-constants-gen.py", line 182, in `<module>`
[ 64s] Generator(argv[0], xml.dom.minidom.parse(argv[1]), argv[2])()
[ 64s] File "../tools/c-constants-gen.py", line 24, in __call__
[ 64s] file_set_contents(self.output_base + '.h', ''.join(self.__header))
[ 64s] File "/home/abuild/rpmbuild/BUILD/telepathy-gabble-0.17.3/tools/libtpcodegen.py", line 42, in file_set_contents
[ 64s] os.rename(filename + '.tmp', filename)
[ 64s] OSError: [Errno 2] No such file or directory
[ 64s] /usr/bin/python ../tools/glib-gtypes-generator.py \
[ 64s] _gen/all.xml _gen/gtypes Gabble
[ 64s] make[2]: *** [_gen/enums-gtk-doc.h] Error 1
[ 64s] make[2]: *** Waiting for unfinished jobs....
[ 64s] make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/telepathy-gabble-0.17.3/extensions'
[ 64s] make[1]: *** [all-recursive] Error 1
[ 64s] make[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/telepathy-gabble-0.17.3'
[ 64s] make: *** [all] Error 2
[ 64s] error: Bad exit status from /var/tmp/rpm-tmp.Y0g1MJ (%build)
[ 64s]
using "make -j 1" works around this issuehttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/167Allowing local tube serialization and approvers to append channel identificat...2019-12-09T11:22:26ZBugzilla Migration UserAllowing local tube serialization and approvers to append channel identification info. to offered tube parameters## Submitted by Chandni Verma
Assigned to **Telepathy bugs list**
**[Link to original bug (#57721)](https://bugs.freedesktop.org/show_bug.cgi?id=57721)**
## Description
How are older channels identified? Should URNs/UUIDs be used ...## Submitted by Chandni Verma
Assigned to **Telepathy bugs list**
**[Link to original bug (#57721)](https://bugs.freedesktop.org/show_bug.cgi?id=57721)**
## Description
How are older channels identified? Should URNs/UUIDs be used which can collide so are bad and there are users not willing to establish a whole new ID system?
I propose it should be possible for the "parameters" property of dbus-tubes to be allowed to be able to add in some more parameters (eg. local data such as path to the older channel-data-file to resume or key to some local database) before invoking the handler?
Since if the file doesn't exist, the user might want to not play the game, so searching for it is the task of the approver and re-searching in the handler to actually continue would be nothing but a repetition of approver's processing.
I haven't yet looked into how to approach this implementation or what could be the implications preventing it.https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/166Empathy unread notifications are lost on disconnect2019-12-09T11:22:24ZBugzilla Migration UserEmpathy unread notifications are lost on disconnect## Submitted by ped..@..il.com
Assigned to **Telepathy bugs list**
**[Link to original bug (#56951)](https://bugs.freedesktop.org/show_bug.cgi?id=56951)**
## Description
I'm losing unread messages (as an icon on 'systray') everyti...## Submitted by ped..@..il.com
Assigned to **Telepathy bugs list**
**[Link to original bug (#56951)](https://bugs.freedesktop.org/show_bug.cgi?id=56951)**
## Description
I'm losing unread messages (as an icon on 'systray') everytime there is a disconnect.
This has been happening frequently so here are the steps to reproduce:
* connect using gabble (I'm using Facebook (g-o-a) & Live (g-o-a) but
should be irrelevant)
* receive messages and don't read them
* sudo wpa_cli terminate
* check that no unread messages are on 'systray'
I'm told this is a 'known issue' so I'm guessing this happens on Gnome 3.6 as well -- personally, I'm on Gnome 3.4.
IMO:
General case is: people should not lose unread messages on all other accounts just because wireless dropped or they had to suspend in a hurry.
Skype is a special case (e.g., stores 'server'-side read status or something), and if people are using multiple devices it further adds enthropy to this discussion. But on current single computer usage, current behaviour is broken and worse than Pidgin, for example.
If gnome-shell is to be used for example, on a tablet, it is not to be expected people will read unread messages before disconnecting WiFi.https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/165tpf-persona.vala:841: Failed to parse new birthday string2019-12-09T11:22:21ZBugzilla Migration Usertpf-persona.vala:841: Failed to parse new birthday string## Submitted by Matteo Settenvini
Assigned to **Telepathy bugs list**
**[Link to original bug (#52413)](https://bugs.freedesktop.org/show_bug.cgi?id=52413)**
## Description
Hello,
every time I start Empathy, I get this error a co...## Submitted by Matteo Settenvini
Assigned to **Telepathy bugs list**
**[Link to original bug (#52413)](https://bugs.freedesktop.org/show_bug.cgi?id=52413)**
## Description
Hello,
every time I start Empathy, I get this error a couple of times:
(empathy:25702): telepathy-WARNING **: tpf-persona.vala:841: Failed to parse new birthday string 'Sat 28 Apr 1984'
That birthday string comes from GMail contacts, I have a XMPP account setup with GNOME Online Accounts.
This would not be a problem, only Empathy shows no contacts in its windows, and it might be related. Even if it's not, it still looks like a bug :-).https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/164Make logging TP components easier2019-12-09T11:22:16ZBugzilla Migration UserMake logging TP components easier## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#43881)](https://bugs.freedesktop.org/show_bug.cgi?id=43881)**
## Description
I often find myself needing the full logs o...## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#43881)](https://bugs.freedesktop.org/show_bug.cgi?id=43881)**
## Description
I often find myself needing the full logs of a TP component (generally a CM). I usually manually restart the CM with, say, GABBLE_DEBUG=all GABBLE_LOGFILE=/tmp/gabble.log and then pray to be able to reproduce the issue I noticed.
As a Telepathy developer I'm interested in most CMs and may find myself needing logs from basically as CM. I could tweak my session add define a *_DEBUG and *_LOGFILE variable for any CM but that's kinda lame and doesn't really scale.
So I'm proposing to add a couple of generic TP variables:
- TP_DEBUG : if the CM specific *_DEBUG variable is not present we use this one
- TP_LOGDIR: if the CM specific *_LOGFILE variable is not present, we log the debug output to TP_LOGDIR/$cm-name.log
That way I'd just have to define "TP_DEBUG=all TP_LOGDIR=/tmp/telepathy-logs/" and be done.
Note that would also make debugging easier for bug reporters as they wouldn't have to play with a billion env variables any more.
So, crack or not?https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/163better handling of connectivity changes: make CMs use GNetworkMonitor and/or ...2019-12-09T11:22:10ZBugzilla Migration Userbetter handling of connectivity changes: make CMs use GNetworkMonitor and/or netlink## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#41148)](https://bugs.freedesktop.org/show_bug.cgi?id=41148)**
## Description
Original bug report: https://bugzilla.gnome...## Submitted by Guillaume Desmottes `@gdesmott`
Assigned to **Telepathy bugs list**
**[Link to original bug (#41148)](https://bugs.freedesktop.org/show_bug.cgi?id=41148)**
## Description
Original bug report: https://bugzilla.gnome.org/show_bug.cgi?id=659872
(I strongly suggest you to start reading Rob's bug reports on this issue).
- Connect your laptop to your docking station and make sure you have a wired (through the dock) and a wifi connection connected.
- Remove it from the docking station; the wired connectivity is lost and the wifi one becomes the default
- Empathy doesn't notice the connectivity change; each CM has to times out before reconnecting
Expected results: all the accounts are reconnected.
The main issue here is that we are relying exclusively on NM_STATE
changes to detect connectivity changes. This used to work fine when NM was
keeping only one connection at a time as a drop of this connection resulted in
a state change. But that's not the case since NM can now be connected to
different connections at the same time (typically a wired and a wifi
connection).
We should track and watch the default active connection and react propertly when it's changed.
### Depends on
* [Bug 38978](https://bugs.freedesktop.org/show_bug.cgi?id=38978)
### Blocking
* [Bug 40131](https://bugs.freedesktop.org/show_bug.cgi?id=40131)
* [Bug 41150](https://bugs.freedesktop.org/show_bug.cgi?id=41150)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/162Non-latin contact names shown encoded in Jabber2019-12-09T11:22:06ZBugzilla Migration UserNon-latin contact names shown encoded in Jabber## Submitted by Ivan Mashchenko
Assigned to **Telepathy bugs list**
**[Link to original bug (#33202)](https://bugs.freedesktop.org/show_bug.cgi?id=33202)**
## Description
If I use non-latin characters to name a Jabber contact, the...## Submitted by Ivan Mashchenko
Assigned to **Telepathy bugs list**
**[Link to original bug (#33202)](https://bugs.freedesktop.org/show_bug.cgi?id=33202)**
## Description
If I use non-latin characters to name a Jabber contact, then &#nnn; codes are shown instead of non-latin letters in chat windows' titles as well as in contact list.
Contact list may show correct (readable, non-encoded) name until restart.
Tested with cyrillic letters on Ubuntu 10.10 x86 en_GB, Empathy 2.32.1.https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/161Too many asynchronous setup steps needed for basic usage2019-12-09T11:21:56ZBugzilla Migration UserToo many asynchronous setup steps needed for basic usage## Submitted by Olli Salli `@oggis`
Assigned to **Telepathy bugs list**
**[Link to original bug (#29451)](https://bugs.freedesktop.org/show_bug.cgi?id=29451)**
## Description
Telepathy-Qt4 has a model to avoid making synchronous D...## Submitted by Olli Salli `@oggis`
Assigned to **Telepathy bugs list**
**[Link to original bug (#29451)](https://bugs.freedesktop.org/show_bug.cgi?id=29451)**
## Description
Telepathy-Qt4 has a model to avoid making synchronous D-Bus calls when creating proxy objects where no state download over D-Bus is initially done, but only started when the application calls becomeReady() on the object with the desired "features" (optional functionality items, each one causing additional D-Bus state download round-trips and potentially more wakeups on state changes). The state download getting finished is signaled using a Qt signal finished() on the PendingOperation subclass returned from the becomeReady() call.
While this approach guarantees no synchronous D-Bus calls (potentially causing deadlocks and reduced responsibility in general) are made, and allows synchronous cached access to the downloaded data afterwards, the initial setup code in applications becomes very complex. Real-world use cases require setting up at least (in order) AccountManager, Account and Connection objects, with each stage requiring an asynchronous wait for the object to become ready before requesting the next level of object. In addition, there is more waiting for signals required:
- A ready Account signals haveConnectionChanged() when it can form a Connection object corresponding to the connection to that account
- Waiting the Connection to become Connected once you have it
- Building Contact objects and/or upgrading them to have more features requires an async step
- "Upgrading" objects to have more features requires yet another becomeReady() and finished() wait just like Contacts
It should be kept in mind that any operation really requiring additional info to be fetched from the CM does and always will require asynchronous logic. This is simply the nature of using objects with data and methods with return values over a message-passing system like D-Bus. However, we could reduce the amount of async setup steps by doing the likely next step in advance, for example:
* allow specifying which Account features should be ready in any Account an AccountManager gives you, and make AccountManager make them ready before signaling accountCreated() and signaling itself being ready in the initial accounts download on AM::becomeReady() -> no need to do Account::becomeReady() on accounts from the AM
* allow specifying which Connection features (on which Connection subclass) should be made ready before signaling Account::haveConnectionChanged(true) -> no need to do Connection::becomeReady() on whatever Account::connection() gives you
* allow specifying which Contact features should always be ready for whatever is in ContactManager::allKnownContacts()
* allow specifying which Contact features should always be ready for a contact signaled as having joined a Channel (this should be documented as dangerous if used with too many features - if the contact in question leaves the channel before we finish introspecting every feature, the operation may fail and we won't necessarily even know who it was)
* allow specifying which Channel features are always interesting for any given channel class, so that Channels given to you when you're a Client or when you request one in general are always ready with the desired features (requires extending ChannelFactory to accept dynamically overriding which Channel subtypes to construct, and which features to begin making ready for a given set of immutable properties making up the channel class)
I'll file the corresponding sub-bugs as dependencies when I have time to do so. Suggestions, especially turning in more superfluous setup step suspects kindly welcome. The suggestions above can be implemented in a backwards-compatible fashion, but we should identify beneficial candidates for an API/ABI break too.
The basic assumption above is that each application has a basic set of features they're always interested in, and will want for every object. Stuff that an application is only potentially interested in (menu option to show eg. avatars for chat participants, the user opening a "more gory details on your friend" expander widget, and so on) can always be "upgraded" afterwards on top of the base set in the current fashion (becomeReady() with more features, upgradeContacts()). Also, in more sophisticated applications, whatever can be lazily updated to the view, should be lazily updated after an upgrade operation finishes, and should be documented as the recommended action in tp-qt4 docs.
One final point is - whatever we do, this shouldn't counteract trying to avoid extra D-Bus state download and signal connections to uninteresting information (forcing Features on etc). Also, we shouldn't hamper subclassability. Even if Account constructs Connection objects for you you should be able to specify the Connection subclass and desired Connection features, etc. This could be accomplished in general using a factory pattern, where you specify a factory function returning the desired subclass and the features to always make ready in constructed objects.
To keep the factories simple, they should only begin the process of making the desired Features ready (and do the other misc manipulation on the constructed object). The constructed object should be returned immediately. The object (eg. AM) which requested constructing the object (the Account) should then wait for the object to get ready, with no further interaction with the factory for that object.
Version: git master
### Depends on
* [Bug 29528](https://bugs.freedesktop.org/show_bug.cgi?id=29528)
* [Bug 29529](https://bugs.freedesktop.org/show_bug.cgi?id=29529)
* [Bug 29606](https://bugs.freedesktop.org/show_bug.cgi?id=29606)
* [Bug 29609](https://bugs.freedesktop.org/show_bug.cgi?id=29609)
* [Bug 29614](https://bugs.freedesktop.org/show_bug.cgi?id=29614)
* [Bug 29619](https://bugs.freedesktop.org/show_bug.cgi?id=29619)
* [Bug 29973](https://bugs.freedesktop.org/show_bug.cgi?id=29973)https://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/160[Muji] crash when establishing a video call (2 people)2019-12-09T11:21:54ZBugzilla Migration User[Muji] crash when establishing a video call (2 people)## Submitted by Yann
Assigned to **Telepathy bugs list**
**[Link to original bug (#28886)](https://bugs.freedesktop.org/show_bug.cgi?id=28886)**
## Description
(was first reported here: https://bugzilla.gnome.org/show_bug.cgi?id=6...## Submitted by Yann
Assigned to **Telepathy bugs list**
**[Link to original bug (#28886)](https://bugs.freedesktop.org/show_bug.cgi?id=28886)**
## Description
(was first reported here: https://bugzilla.gnome.org/show_bug.cgi?id=622950 )
On Muji, 2 EmpathyPPA. We both have jabber.fr accounts. We both launch Muji
with "Conference".
I was on ubuntu-fr@chat.jabberfr.org with status "Accepted" (could see my
video).
Another user comes, I can see him in Muji. He tells me he has also the status
"accepted".
There my Muji crashes. My correspondant's Muji does not crash.
My log :
$ VIDEO_DEVICE=/dev/video0 python new-call-demo/callui.py
* starting audio call
Showing window
* StateChanged:
State: Pending Initiator (1)
Flags: None
Reason: actor: 0 reason: 0 dbus_reason: ''
Details:
None
* StateChanged:
State: Pending Receiver (2)
Flags: None
Reason: actor: 0 reason: 0 dbus_reason: ''
Details:
None
* StateChanged:
State: Accepted (3)
Flags: None
Reason: actor: 0 reason: 0 dbus_reason: ''
Details:
None
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
Adding frame to position 1
** (callui.py:6582): WARNING **: Error creating GUPnP context: Ressource
temporairement non disponible
Erreur de segmentation (core dumped)
**************************:
My correspondant's log:
VIDEO_DEVICE=/dev/video0 python new-call-demo/callui.py
/usr/share/themes/Win2-7Original/gtk-2.0/gtkrc:844: Incapable de localiser le
fichier image dans le chemin des pixmaps : « Panel/panel-bg-30px.png »
* starting video call
Showing window
* StateChanged:
State: Pending Initiator (1)
Flags: None
Reason: actor: 0 reason: 0 dbus_reason: ''
Details:
None
Adding frame to position 1
* StateChanged:
State: Pending Receiver (2)
Flags: None
Reason: actor: 0 reason: 0 dbus_reason: ''
Details:
None
* StateChanged:
State: Accepted (3)
Flags: None
Reason: actor: 0 reason: 0 dbus_reason: ''
Details:
None
* StateChanged:
State: Ended (4)
Flags: None
Reason: actor: 0 reason: 0 dbus_reason: ''
Details:
None
Traceback (most recent call last):
* File "/home/paul/new-call-demo/callchannelui.py", line 335 in window_closed
self.channel.conference.pipeline.remove(v.sink)
AttributeError: 'NoneType' object has no attribute 'pipeline'
* StateChanged:
State: Ended (4)
Flags: None
Reason: actor: 0 reason: 0 dbus_reason: ''
Details:
Nonehttps://gitlab.freedesktop.org/telepathy/telepathy-spec/-/issues/159[Muji] Crash when exiting a conference2019-12-09T11:21:52ZBugzilla Migration User[Muji] Crash when exiting a conference## Submitted by Yann
Assigned to **Telepathy bugs list**
**[Link to original bug (#28885)](https://bugs.freedesktop.org/show_bug.cgi?id=28885)**
## Description
(was first reported on : https://bugzilla.gnome.org/show_bug.cgi?id=62...## Submitted by Yann
Assigned to **Telepathy bugs list**
**[Link to original bug (#28885)](https://bugs.freedesktop.org/show_bug.cgi?id=28885)**
## Description
(was first reported on : https://bugzilla.gnome.org/show_bug.cgi?id=622947)
on EmpathyPPA, Muji
I was connected on Muji with my Jabber account. Status "Accepted" (could see my
webcam).
I HangOut the call, then closed the 2nd Muji window (the one with the webcam).
There the 1st (main) Muji window disappeared. (generally it remains).
Log:
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffec
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fffe
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fffb
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffec
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fff6
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffec
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffec
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fff6
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fffd
Traceback (most recent call last):
* File "/home/yyy/new-call-demo/callchannelui.py", line 103 in `<lambda>`
CALL_STATE_CHANGE_REASON_REQUESTED,"", "Hangup clicked"))
* File "/home/yyy/new-call-demo/callchannel.py", line 436 in hangup
dbus_interface=CHANNEL_TYPE_CALL)
* File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140 in __call__
**keywords)
* File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620 in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.151 was not provided by any .service files
name :1.151 was not provided by any .service files
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fff6
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
Traceback (most recent call last):
File "/home/yyy/new-call-demo/callchannelui.py", line 322, in window_closed
"", "User closed the window")
File "/home/yyy/new-call-demo/callchannel.py", line 436, in hangup
dbus_interface=CHANNEL_TYPE_CALL)
File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in __call__
**keywords)
File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The
name :1.151 was not provided by any .service files
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
The program 'callui.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 27120 error_code 3 request_code 3 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
*******************Another similar crash******************
This time: I was "Accepted" in the room.
I closed the window (with the video), without clicking "Hang out".
The main Muji window also crashed.
Log:
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffd9
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000fffe
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
libv4lconvert: Error decompressing JPEG: unknown huffman code: 0000ffff
Traceback (most recent call last):
* File "/home/yyy/new-call-demo/callchannelui.py", line 322 in window_closed
"", "User closed the window")
* File "/home/yyy/new-call-demo/callchannel.py", line 436 in hangup
dbus_interface=CHANNEL_TYPE_CALL)
* File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140 in __call__
**keywords)
* File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620 in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.437 was not provided by any .service files
name :1.437 was not provided by any .service files
The program 'callui.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 18600 error_code 3 request_code 3 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)