http://permalink.gmane.org/gmane.comp.freedesktop.telepathy hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6066 <pre> I would be happy to review patches on Bugzilla for --enable-installed-tests, particularly if they are compatible with what Colin Walters is advocating for GNOME (analogous to CITA but with a .desktop-style file per test instead of tests.xml). I would prefer tests in a subdirectory of ${libdir} and/or ${datadir} by default (the latter is only OK if everything is architecture-independent). If you want the directory to be configurable, I'd prefer that to work like Gabble's plugins: if test "x$pluginexeclibdir" = x; then pluginexeclibdir='${libdir}/telepathy/gabble-0/lib' fi AC_ARG_VAR([pluginexeclibdir]) which means you can "./configure ... pluginexeclibdir=/foo/bar" and that will be enough. Strictly speaking, the variable name should include "exec" if its contents will contain any native code (so perhaps installedtestexecdir or something). It could default to ${pkglibdir}/tests, maybe? Regards, S </pre> Simon McVittie 2013-05-07T13:06:05 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6065 <pre>Hi, On 07.05.2013 15:40, Simon McVittie wrote: No good reason :-) just a matter of taste. Mer/Nemo decided to have tests in /opt/tests/packagename/. But is not a hard requirement. Since we now check with rpm -ql where the tests.xml file is of a tests package. I also patch other tp-* packages, to make the tests installable. Would you guys be open for patches to make that configurable (target) and optional? Yes that would be easier in .spec than to patch :-) br Reto </pre> Reto Zingg 2013-05-07T12:53:59 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6064 <pre> No, when MC is started "realistically", it will see the real system bus, unless you take steps for it not to do so. The default is for DBUS_SYSTEM_BUS_ADDRESS to be unset, which results in libdbus (and GDBus, etc.) using a compile-time default, usually unix:/var/run/dbus/system_bus_socket. This is the real system bus. S </pre> Simon McVittie 2013-05-07T12:43:55 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6063 <pre> This will break any future things in MC that need the genuine system bus, but OK; "make check" would also break, so we'd need to deal with that one way or another. Is there any particular reason for using a different location? If there is a good reason, then we should change it or make it configurable. Patching shouldn't be needed anyway, you can "make mctestsdir=/foo", "make install mctestsdir=/foo" if necessary. S </pre> Simon McVittie 2013-05-07T12:40:15 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6062 <pre>Hi, On 07.05.2013 15:08, Simon McVittie wrote: it seems that tp-m-c started from dbus does not get that! I added some output to run-mc.sh, but DBUS_SYSTEM_BUS_ADDRESS was empty! Seems dbus strips some env vars out? So I added DBUS_SYSTEM_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS" to run-mc.sh now it works, see patch[1]. yes --enable-installed-tests is set, just the install directory I patch to an other location. it seems with the above mentioned patch it just works now?! Yes we run it in similar manner as CITA. I noticed that bug this morning. Let's see what it changes :-) Thanks and best regards Reto [1] https://build.merproject.org/package/view_file?file=nemo-fix-system-dbus-for-tests.patch&amp;package=telepathy-mission-control&amp;project=nemo%3Adevel%3Amw&amp;rev=21dd75c1aa7a06f849485c851fccf911 </pre> Reto Zingg 2013-05-07T12:33:48 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6061 <pre> This is how it works during "make check". It emulates both ConnMan and NetworkManager (simultaneously!), in fact. We set DBUS_SYSTEM_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS" when executing MC, so that MC thinks the fake session bus is the real system bus. This is how it works during "make check". Is this using --enable-installed-tests (which you might remember us using for CITA in Maemo)? If so, you will probably have to support it yourself if you want it. The configuration we test ourselves (i.e. the one I ran when making the releases) is "make check" and "make distcheck", running the tests inside the built tree. This is also somewhat more thorough than the installed tests, because we use a debug version of MC that can be manipulated by the tests. It is entirely possible that the installed tests are broken in situations where ConnMan doesn't think you have connectivity: MC (correctly!) refuses to go online there. You might need to run the MC tests with a fake ConnMan that always says "yes, I am online"</pre> Simon McVittie 2013-05-07T12:08:48 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6060 <pre>Hi, I have some problems with running the TP-Mission-Control tests. Version is 5.15.0, and packages are from Nemo[1]. I run the tests with the run-test.sh script, so it set's up own dbus session bus. As far as I can tell it does use that one (I don't see e.g. anything on user session/system dbus). Tests run fine and pass on device and virtual images, when connman is running and has a connection (is online). But when: - connman is not running (virtual image) - connman is running but no WLAN/3g network is available (maintained by connmand, just usb0 connection but not maintained by connman (--nodevice=usb*)) then many tests fail. It already fails during "test set up". example: dispatcher/vanishing-client.py Traceback (most recent call last): File "/opt/tests/telepathy-mission-control/twisted/mctest.py", line 133, in exec_test_deferred fun(queue, bus, mc) File "/opt/tests/telepathy-mission-control/twisted/dispatcher/vanishing-client.py", line 37, in test conn = enable_fakecm_account(q, bus,</pre> Reto Zingg 2013-05-07T07:55:09 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6059 <pre>The “any other citizen of the Queen” release. This starts a development branch. It adds features, and probably exciting new bugs too. Running this version of Mission Control for the first time will automatically migrate some account data to a new format. If you subsequently downgrade to an older version, it will no longer understand all account data. Taking a backup copy of ~/.local/share/telepathy/mission-control before you upgrade is recommended. tarball: http://telepathy.freedesktop.org/releases/telepathy-mission-control/telepathy-mission-control-5.15.0.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-mission-control/telepathy-mission-control-5.15.0.tar.gz.asc Requirements: • GLib 2.32 is now required. • The regression tests now require Python 2.6. Deprecations: • McpAccountStorage::altered, which appears to have never worked, is now deprecated (fd.o #28288). Emit ::altered-one instead. • mcp_account_storage_iface_set_priority() etc. are now deprecated. Use, fo</pre> Simon McVittie 2013-05-03T14:37:04 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6058 <pre>Empathy 3.9.1 is now available for download from: http://download.gnome.org/sources/empathy/3.9/ 6a07b9a302f4f5f8b82fb5fba552c858 empathy-3.9.1.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? =========== Bugs fixed: - Fixed #692160, Updated Icon Names (B.Prathibha) - Fixed #697214, call-window: Remember that the audio output has been added (Olivier Crête) - Fixed #697302, Spelling mistake: "You need to setup an account..." (SandipTiwari) - Fixed #699017, libempathy: Fix build by adding missing math.h header (Stef Walter) - Fixed #673775, The icon for audio call in the help is wrong. (Ekaterina Gerasimova) - Fixed #677549, "Link Contacts" user</pre> Guillaume Desmottes 2013-05-03T13:04:44 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6057 <pre>The “implicit maze” release. tarball: http://telepathy.freedesktop.org/releases/telepathy-mission-control/telepathy-mission-control-5.14.1.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-mission-control/telepathy-mission-control-5.14.1.tar.gz.asc Fixes: • Only ignore passwords stored in our old gnome-keyring location if Empathy has actually copied them to its new location, fixing use of a gnome-keyring-enabled MC version with no Empathy or other SASLAuthentication handler (e.g. under Sugar). (fd.o #59468, Simon) • Build successfully with Automake 1.13 (fd.o #59605, Nuno Araujo) • Isolate regression tests better (fd.o #63119, Simon McVittie) • Respect NOCONFIGURE in autogen.sh (fd.o #57165, Cosimo Cecchi) </pre> Simon McVittie 2013-05-03T11:24:26 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6056 <pre> For the record, this is now called CVE-2007-6746. This is fixed in 0.1.16. S </pre> Simon McVittie 2013-05-01T15:51:16 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6055 <pre>The “smörgåsbord of crashes” release. tarball: http://telepathy.freedesktop.org/releases/telepathy-idle/telepathy-idle-0.1.16.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-idle/telepathy-idle-0.1.16.tar.gz.asc git: http://cgit.freedesktop.org/telepathy/telepathy-idle Enhancements: • Add support for interactive TLS certificate validation, fixing the regression in 0.1.15 that self-signed certificates could not be used any more. (fd.o #57130; Sjoerd, Will) </pre> Simon McVittie 2013-05-01T15:49:02 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6054 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/7/13 3:50 PM, Travis Reitter wrote: Hi Travis. A very belated thanks for your feedback! Emil has already incorporated much of your feedback into the spec, but I've also just added the second sentence to the following paragraph: In addition to discovering phone numbers from vCards, clients may also check for alternative communication methods as advertised in XMPP presence broadcasts and Personal Eventing Protocol nodes as described in &lt;xref target="XEP-0152"&gt; XEP-0152: Reachability Addresses&lt;/xref&gt;. However, these indications are merely hints, and a receiving client ought not associate a SIP address and an XMPP address unless it has some way to verify the association (e.g., the vCard of the XMPP account lists the SIP address and the vCard of the SIP account lists the XMPP address). (I've also corrected the spelling of your last name.) Yes, we've published several versions</pre> Peter Saint-Andre 2013-04-30T02:20:10 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6053 <pre>El lun, 22-04-2013 a las 12:11 -0700, Travis Reitter escribió: This could be a step towards a folksd. How necessary is this? I think we should only add something like this in response to profiling, once the other optimisations (such as an aggregation cache) have been implemented. It might turn out to be unnecessary. Not that I can think of. Philip _______________________________________________ telepathy mailing list telepathy&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy </pre> Philip Withnall 2013-04-27T15:11:46 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6052 <pre>The “secure by default“ release. This fixes missing certificate validation in IRC-over-SSL (CVE ID not yet issued). Upgrading is recommended. Distributors who ship versions 0.1.11-0.1.14 can correct this flaw by removing the call to g_socket_client_set_tls_validation_flags(), similar to [1]. Versions 0.1.10 and older do not validate certificates at all; no patch is available for these releases. tarball: http://telepathy.freedesktop.org/releases/telepathy-idle/telepathy-idle-0.1.15.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-idle/telepathy-idle-0.1.15.tar.gz.asc git: http://cgit.freedesktop.org/telepathy/telepathy-idle Fixes: • Validate TLS certificates properly, preventing man-in-the-middle attacks. (fd.o#63810, Simon) This will be a regression for users of IRC-over-SSL servers/proxies that do not have a certificate trusted by system-wide CA configuration; they will no longer be able to connect. If someone implements fd.o #57130, that will provide the ability </pre> Simon McVittie 2013-04-24T16:07:49 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6051 <pre> Note that the Folks potential matches API is already based upon Marco's plugin (at least, the name-matching part). Recent versions of Gnome Contacts use it to suggest linking the currently-viewed Individual to other personas. Regards, -Travis _______________________________________________ telepathy mailing list telepathy&lt; at &gt;lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy </pre> Travis Reitter 2013-04-22T20:05:44 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6050 <pre> Good to hear about that huge speed-up. Have you tried it with a Google account in EDS with ~6,000 contacts? That's the slowest use case for Folks currently. See https://bugzilla.gnome.org/show_bug.cgi?id=689549 Just glancing over the API very briefly, a few things stand out: * I'm assuming your "merging" is non-destructive as it is in Folks. If so, I'd be careful to always refer to it as "linking" which apparently is much clearer to users (that's why we've used that language ourselves) and obviously it's preferable to actually-destructive merging, as we know from Maemo. Since it's really a single concept in both the implementation and UI, we might as well be consistent with the language * I recommend adding API for favorites early on. We underestimated how important that is in Folks, I think. Outside of roster-based chat clients, favorites are often what you care the most about (and certainly want to prioritize over the rest of the roster/address book). * And I'd recommend search fun</pre> Travis Reitter 2013-04-22T20:03:53 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6049 <pre> Agreed completely. I would be happy to move this functionality from Folks into its backends' implementations. That seems to be the proper place for the caches to exist, since they're generally necessary for those components on their own anyhow. EDS already has its own cache and we just need the vCard and avatar caches for Telepathy you describe above before we could rely upon that and drop the caching in Folks, I think. I think the only caching Folks itself should need would be: * link/aggregation cache (fdo#687671). This wouldn't be a concern for Telepathy itself, but I'm just listing it for completeness. Start-up aggregation for Folks is a lot of repeated work which is mostly redundant for almost all Folks client runs between Telepathy account adds/removes (so, ~all runs). * (possibly) the core vCard (mainly alias/nickname/Full Name) + avatar for favorites in a format that can be displayed extremely quickly. This would be an optimization around worst-case performance risks of the full </pre> Travis Reitter 2013-04-22T19:11:35 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6048 <pre>That is my opinion. Opinions may differ. :-) I think we could have an interesting conversation about this on the XMPP standards list, and you might find some other folks who want to implement this on clients or servers. Personally I'd love to see wider support for TLS-PGP, because it would help us get rid of password-based authentication. There might be some challenges with key management (how do I tell the XMPP server that I've generated a new key?), but key management is always interesting. :-) Peter </pre> Peter Saint-Andre 2013-04-17T16:02:43 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6047 <pre> Indeed. Sure. Just subscribed. But at this point I guess I should go ahead with RFC 6091; implementing a SASL protocol for something which is clearly (and should be, actually) addressed by TLS would be useless don't you think? </pre> Daniele Ricci 2013-04-17T15:57:30 http://permalink.gmane.org/gmane.comp.freedesktop.telepathy/6046 <pre>Sure. You could do something like secure remote password, but if you really want to use PGP then RFC 6091 is the right way to go (IMHO). Perhaps we could discuss this topic on the standards-k2lrwn5/VE4&lt; at &gt;public.gmane.org list? http://mail.jabber.org/mailman/listinfo/standards Peter </pre> Peter Saint-Andre 2013-04-17T15:52:12 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.freedesktop.telepathy