cd ~/src/ytsenut-plugins
# we will need to point to the salut and tp-ytstenut we just built.
./autogen.sh PKG_CONFIG_PATH=$HOME/src/telepathy-ytstenut/telepathy-ytstenut-glib:$HOME/src/telepathy-salut/salut
make

Test to see the tests still pass.

cd ~/src/ytstenut-plugins
make check

Build ytstenut-glib. This is the library that applications will build against.

cd ~/src/ytsenut-glib
# we will need to point to the salut and tp-ytstenut we just built.
./autogen.sh --enable-gtk-doc --enable-docs PKG_CONFIG_PATH=$HOME/src/telepathy-ytstenut/telepathy-ytstenut-glib:$HOME/src/telepathy-salut/salut
make

If everything is working, then you can run salut with Ytstenut not in the test suite:

If set then Salut won't timeout due to no connections after five seconds

set to anything, but we typically use SALUT_PERSIST=1

SALUT_DEBUG

Whether Salut should log stuff to stdout

any log flag will work, but all is recommended

WOCKY_DEBUG

Whether Wocky should log stuff to stdout

same as above, use all

SALUT_PLUGIN_DIR

The directory for Salut to look in for plugins (like the Ytstenut one) if not /usr/lib/telepathy/salut-0

we will want to set it to the directory the Ytstenut plugin is in. If you've not installed anything, like above, then the plugin source is in ~/src/ytstenut-plugins/salut/ but the actual .so file is in the /.libs subdirectory due to libtool, hence the setting in the above example

Mission Control

First make sure you don't have a salut.manager file in /usr/share/telepathy/. If you do this will trigger #22 (fixed by now). Systems using Ytstenut should not distribute a manager file. A manager file just contains information about a connection manager and what it does so that it can be read by Mission Control. However, because we have a Ytstenut Salut plugin and so a Ytstenut protocol the manager file is wrong. Not having this file simply means that Mission Control will start the connection manager (Salut in our case) and introspect it manually. This is good. This is what we want.

Tests ?TpYtsAccountManager by calling Hold(), getting the automatic account from the Mission Control plugin, and finally calling Release().

client-ping

Tests sending an arbitrary message to another service. The first argument is the local service name and the second is the remote service name. The remote service should be running on the same machine. This has only been tested with the client-pong test. Waits for a reply and prints the reply and quits.

client-pong

Returns the arbitrary message from client-ping with some more rubbish. Waits for a message, prints it, replies, and quits. The first argument is the local service name which you pass as the second argument to client-ping.

nosey-status

A bit like dbus-monitor, but for Ytstenut services. Every time ?ServiceAdded, ?ServiceRemoved or ?StatusChanged is emitted by the Status sidecar in the Salut plugin, this test will print out details. Bear in mind that ?StatusChanged is only emitted on non-local services where it shows an interest. This test advertises only one interest: urn:ytstenut:capabilities:yts-caps-cats, so if you want this to print ?StatusChanged for you from a non-local service, your capability either has to be that or you have to change the test to add another interest.

passing-service

A simple test to pop up a new service, and then disappear after a few seconds and quits. The first argument is the local service name. You can see the service appearing and then disappearing if you run nosey-status beforehand.

passing-status

Similar to passing-service but it pops up a service, advertises a status, waits a few seconds, clears the status, waits a few more seconds, then quits. The service name is currently hard-coded. The status which is advertised uses the urn:ytstenut:capabilities:yts-caps-cats capability so it needs no changes when nosey-status is being used.

A note about capabilities, interests and StatusChanged

then this means that any service on the network which advertise statuses with the same capability will notify said interested service. Please note, however, that this only applies to non-local services. When one advertises a status, a PEP node is published and Salut goes through its contacts looking at their capabilities to see who to send the node to -- this is the reason for the adding interest. However, the PEP XEP also states that the message must be sent to the local user from where it originated. As a result, any status you advertise will also appear in the local ?TpYtsStatus. Just something to keep in mind, so filtering of ?StatusChanged signals must always be done.

cd ~/src/ytsenut-plugins
# we will need to point to the gabble and tp-ytstenut we just built.
./autogen.sh PKG_CONFIG_PATH=$HOME/src/telepathy-ytstenut/telepathy-ytstenut-glib:$HOME/src/telepathy-gabble/gabble
make

Test to see the tests still pass.

cd ~/src/ytstenut-plugins
make check

Build ytstenut-glib. This is the library that applications will build against.

cd ~/src/ytsenut-glib
# we will need to point to the gabble and tp-ytstenut we just built.
./autogen.sh --enable-gtk-doc --enable-docs PKG_CONFIG_PATH=$HOME/src/telepathy-ytstenut/telepathy-ytstenut-glib:$HOME/src/telepathy-gabble/gabble
make

If everything is working, then you can run gabble with Ytstenut not in the test suite:

If set then Gabble won't timeout due to no connections after five seconds

set to anything, but we typically use GABBLE_PERSIST=1

GABBLE_DEBUG

Whether Gabble should log stuff to stdout

any log flag will work, but all is recommended (easiest)

WOCKY_DEBUG

Whether Wocky should log stuff to stdout

same as above, use all

GABBLE_PLUGIN_DIR

The directory for Gabble to look in for plugins (like the Ytstenut one) if not /usr/lib/telepathy/gabble-0

we will want to set it to the directory the Ytstenut plugin is in. If you've not installed anything, like above, then the plugin source is in ~/src/ytstenut-plugins/gabble/ but the actual .so file is in the /.libs subdirectory due to libtool, hence the setting in the above example

There are some telepathy-ytstenut-glib tests for gabble. These are exactly the same as the ones for salut but the binaries start with "server-" and they take an account triple as the first argument. For example, instead of: