Attachment 74208 Details for Bug 59805 – Moved docbook source used by cmake to doc subdir

[patch] Moved docbook source used by cmake to doc subdir

0001-Moved-docbook-sources-used-by-cmake-into-doc-subdir-.patch (text/plain), 161.23 KB, created by Ralf Habacker on 2013-02-05 00:44:53 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Ralf Habacker

Created: 2013-02-05 00:44:53 UTC

Size: 161.23 KB

patch

obsolete

>From 856e9e3141a76e2cdfea5776bfe08e8311f50d16 Mon Sep 17 00:00:00 2001
>From: Ralf Habacker <ralf.habacker@freenet.de>
>Date: Tue, 5 Feb 2013 01:20:46 +0100
>Subject: [PATCH] Moved docbook sources used by cmake into doc subdir and
> adapted cmake build system.
>
>Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59805
>---
> cmake/bus/dbus-daemon.xml    |  752 -----------------------------------
> cmake/doc/CMakeLists.txt     |    9 +-
> cmake/tools/dbus-launch.xml  |  240 ------------
> cmake/tools/dbus-monitor.xml |  121 ------
> cmake/tools/dbus-send.xml    |  143 -------
> doc/dbus-daemon.1.xml.in     |  888 ++++++++++++++++++++++++++++++++++++++++++
> doc/dbus-daemon.xml.in       |  752 +++++++++++++++++++++++++++++++++++
> doc/dbus-launch.1.xml        |  270 +++++++++++++
> doc/dbus-launch.xml          |  240 ++++++++++++
> doc/dbus-monitor.1.xml       |  121 ++++++
> doc/dbus-monitor.xml         |  121 ++++++
> doc/dbus-send.1.xml          |  157 ++++++++
> doc/dbus-send.xml            |  143 +++++++
> doc/dbus-uuidgen.1.xml       |  125 ++++++
> 14 Dateien geÃ¤ndert, 2822 Zeilen hinzugefÃ¼gt(+), 1260 Zeilen entfernt(-)
> delete mode 100644 cmake/bus/dbus-daemon.xml
> delete mode 100644 cmake/tools/dbus-launch.xml
> delete mode 100644 cmake/tools/dbus-monitor.xml
> delete mode 100644 cmake/tools/dbus-send.xml
> create mode 100644 doc/dbus-daemon.1.xml.in
> create mode 100644 doc/dbus-daemon.xml.in
> create mode 100644 doc/dbus-launch.1.xml
> create mode 100644 doc/dbus-launch.xml
> create mode 100644 doc/dbus-monitor.1.xml
> create mode 100644 doc/dbus-monitor.xml
> create mode 100644 doc/dbus-send.1.xml
> create mode 100644 doc/dbus-send.xml
> create mode 100644 doc/dbus-uuidgen.1.xml
>
>diff --git a/cmake/bus/dbus-daemon.xml b/cmake/bus/dbus-daemon.xml
>deleted file mode 100644
>index f331699..0000000
>--- a/cmake/bus/dbus-daemon.xml
>+++ /dev/null
>@@ -1,752 +0,0 @@
>-<?xml version="1.0" encoding="ISO-8859-1"?>
>-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
>-                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
>-
>-<refentry id='dbus-daemon'>
>-
>-
>-
>-
>-<refmeta>
>-<refentrytitle>dbus-daemon</refentrytitle>
>-<manvolnum>1</manvolnum>
>-</refmeta>
>-<refnamediv id='name'>
>-<refname>dbus-daemon</refname>
>-<refpurpose>Message bus daemon</refpurpose>
>-</refnamediv>
>-
>-<refsynopsisdiv id='synopsis'>
>-<cmdsynopsis>
>-  <command>dbus-daemon</command></cmdsynopsis>
>-<cmdsynopsis>
>-  <command>dbus-daemon</command>    <arg choice='opt'>--version </arg>
>-    <arg choice='opt'>--session </arg>
>-    <arg choice='opt'>--system </arg>
>-    <arg choice='opt'>--config-file=<replaceable>FILE</replaceable></arg>
>-    <arg choice='opt'><arg choice='plain'>--print-address </arg><arg choice='opt'><replaceable>=DESCRIPTOR</replaceable></arg></arg>
>-    <arg choice='opt'><arg choice='plain'>--print-pid </arg><arg choice='opt'><replaceable>=DESCRIPTOR</replaceable></arg></arg>
>-    <arg choice='opt'>--fork </arg>
>-    <sbr/>
>-</cmdsynopsis>
>-</refsynopsisdiv>
>-
>-
>-<refsect1 id='description'><title>DESCRIPTION</title>
>-<para><command>dbus-daemon</command> is the D-Bus message bus daemon. See
>-<ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about
>-the big picture. D-Bus is first a library that provides one-to-one
>-communication between any two applications; <command>dbus-daemon</command> is an
>-application that uses this library to implement a message bus
>-daemon. Multiple programs connect to the message bus daemon and can
>-exchange messages with one another.</para>
>-
>-
>-<para>There are two standard message bus instances: the systemwide message bus 
>-(installed on many systems as the "messagebus" init service) and the 
>-per-user-login-session message bus (started each time a user logs in).
>-<command>dbus-daemon</command> is used for both of these instances, but with 
>-a different configuration file.</para>
>-
>-
>-<para>The --session option is equivalent to
>-"--config-file=/etc/dbus-1/session.conf" and the --system
>-option is equivalent to
>-"--config-file=/etc/dbus-1/system.conf". By creating 
>-additional configuration files and using the --config-file option,
>-additional special-purpose message bus daemons could be created.</para>
>-
>-
>-<para>The systemwide daemon is normally launched by an init script, 
>-standardly called simply "messagebus".</para> 
>-
>-
>-<para>The systemwide daemon is largely used for broadcasting system events, 
>-such as changes to the printer queue, or adding/removing devices.</para>
>-
>-
>-<para>The per-session daemon is used for various interprocess communication 
>-among desktop applications (however, it is not tied to X or the GUI 
>-in any way).</para>
>-
>-
>-<para>SIGHUP will cause the D-Bus daemon to PARTIALLY reload its
>-configuration file and to flush its user/group information caches. Some
>-configuration changes would require kicking all apps off the bus; so they will
>-only take effect if you restart the daemon. Policy changes should take effect
>-with SIGHUP.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='options'><title>OPTIONS</title>
>-<para>The following options are supported:</para>
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><option>--config-file=FILE</option></term>
>-  <listitem>
>-<para>Use the given configuration file.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--fork</option></term>
>-  <listitem>
>-<para>Force the message bus to fork and become a daemon, even if 
>-the configuration file does not specify that it should.
>-In most contexts the configuration file already gets this
>-right, though.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--print-address[=DESCRIPTOR]</option></term>
>-  <listitem>
>-<para>Print the address of the message bus to standard output, or 
>-to the given file descriptor. This is used by programs that 
>-launch the message bus.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--print-pid[=DESCRIPTOR]</option></term>
>-  <listitem>
>-<para>Print the process ID of the message bus to standard output, or 
>-to the given file descriptor. This is used by programs that 
>-launch the message bus.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--session</option></term>
>-  <listitem>
>-<para>Use the standard configuration file for the per-login-session message
>-bus.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--system</option></term>
>-  <listitem>
>-<para>Use the standard configuration file for the systemwide message bus.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--version</option></term>
>-  <listitem>
>-<para>Print the version of the daemon.</para>
>-
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-</refsect1>
>-
>-<refsect1 id='configuration_file'><title>CONFIGURATION FILE</title>
>-<para>A message bus daemon has a configuration file that specializes it
>-for a particular application. For example, one configuration 
>-file might set up the message bus to be a systemwide message bus, 
>-while another might set it up to be a per-user-login-session bus.</para>
>-
>-
>-<para>The configuration file also establishes resource limits, security
>-parameters, and so forth.</para>
>-
>-
>-<para>The configuration file is not part of any interoperability
>-specification and its backward compatibility is not guaranteed; this
>-document is documentation, not specification.</para>
>-
>-
>-<para>The standard systemwide and per-session message bus setups are
>-configured in the files "/etc/dbus-1/system.conf" and
>-"/etc/dbus-1/session.conf".  These files normally
>-&lt;include&gt; a system-local.conf or session-local.conf; you can put local
>-overrides in those files to avoid modifying the primary configuration
>-files.</para>
>-
>-
>-<para>The configuration file is an XML document. It must have the following
>-doctype declaration:</para>
>-<literallayout remap='.nf'>
>-
>-   &lt;!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
>-    "<ulink url='http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd'>http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd</ulink>"&gt;
>-
>-</literallayout> 
>-
>-
>-<para>The following elements may be present in the configuration file.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;busconfig&gt;</emphasis></term>
>-  <listitem>
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>Root element.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;type&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>The well-known type of the message bus. Currently known values are
>-"system" and "session"; if other values are set, they should be
>-either added to the D-Bus specification, or namespaced.  The last
>-&lt;type&gt; element "wins" (previous values are ignored).</para>
>-
>-
>-<para>Example: &lt;type&gt;session&lt;/type&gt;</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;include&gt;</emphasis></term>
>-  <listitem>
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>Include a file &lt;include&gt;filename.conf&lt;/include&gt; at this point.  If the
>-filename is relative, it is located relative to the configuration file
>-doing the including.</para>
>-
>-
>-<para>&lt;include&gt; has an optional attribute "ignore_missing=(yes|no)"
>-which defaults to "no" if not provided. This attribute 
>-controls whether it's a fatal error for the included file 
>-to be absent.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;includedir&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>Include all files in &lt;includedir&gt;foo.d&lt;/includedir&gt; at this
>-point. Files in the directory are included in undefined order.
>-Only files ending in ".conf" are included.</para>
>-
>-
>-<para>This is intended to allow extension of the system bus by particular
>-packages. For example, if CUPS wants to be able to send out
>-notification of printer queue changes, it could install a file to
>-/etc/dbus-1/system.d that allowed all apps to receive
>-this message and allowed the printer daemon user to send it.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;user&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>The user account the daemon should run as, as either a username or a
>-UID. If the daemon cannot change to this UID on startup, it will exit.
>-If this element is not present, the daemon will not change or care
>-about its UID.</para>
>-
>-
>-<para>The last &lt;user&gt; entry in the file "wins", the others are ignored.</para>
>-
>-
>-<para>The user is changed after the bus has completed initialization.  So
>-sockets etc. will be created before changing user, but no data will be
>-read from clients before changing user. This means that sockets 
>-and PID files can be created in a location that requires root 
>-privileges for writing.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;fork&gt;</emphasis></term>
>-  <listitem>
>-<para></para>    
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>If present, the bus daemon becomes a real daemon (forks 
>-into the background, etc.). This is generally used 
>-rather than the --fork command line option.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;listen&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>Add an address that the bus should listen on. The 
>-address is in the standard D-Bus format that contains 
>-a transport name plus possible parameters/options.</para>
>-
>-
>-<para>Example: &lt;listen&gt;unix:path=/tmp/foo&lt;/listen&gt;</para>
>-
>-
>-<para>If there are multiple &lt;listen&gt; elements, then the bus listens 
>-on multiple addresses. The bus will pass its address to 
>-started services or other interested parties with 
>-the last address given in &lt;listen&gt; first. That is, 
>-apps will try to connect to the last &lt;listen&gt; address first.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;auth&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>Lists permitted authorization mechanisms. If this element doesn't
>-exist, then all known mechanisms are allowed.  If there are multiple
>-&lt;auth&gt; elements, all the listed mechanisms are allowed.  The order in
>-which mechanisms are listed is not meaningful.</para>
>-    
>-
>-<para>Example: &lt;auth&gt;EXTERNAL&lt;/auth&gt;</para>
>-
>-
>-<para>Example: &lt;auth&gt;DBUS_COOKIE_SHA1&lt;/auth&gt;</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;servicedir&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>Adds a directory to scan for .service files. Directories are
>-scanned starting with the last to appear in the config file 
>-(the first .service file found that provides a particular 
>-service will be used).</para>
>-
>-
>-<para>Service files tell the bus how to automatically start a program.
>-They are primarily used with the per-user-session bus, 
>-not the systemwide bus.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;standard_session_servicedirs/&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>&lt;standard_session_servicedirs/&gt; is equivalent to specifying a series
>-of &lt;servicedir/&gt; elements for each of the data directories in the "XDG
>-Base Directory Specification" with the subdirectory "dbus-1/services",
>-so for example "/usr/share/dbus-1/services" would be among the
>-directories searched.</para>
>-
>-
>-<para>The "XDG Base Directory Specification" can be found at
>-<ulink url='http://freedesktop.org/wiki/Standards/basedir-spec'>http://freedesktop.org/wiki/Standards/basedir-spec</ulink> if it hasn't moved,
>-otherwise try your favorite search engine.</para>
>-
>-
>-<para>The &lt;standard_session_servicedirs/&gt; option is only relevant to the
>-per-user-session bus daemon defined in
>-/etc/dbus-1/session.conf. Putting it in any other
>-configuration file would probably be nonsense.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;limit&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>&lt;limit&gt; establishes a resource limit. For example:</para>
>-<literallayout remap='.nf'>
>-  &lt;limit name="max_message_size"&gt;64&lt;/limit&gt;
>-  &lt;limit name="max_completed_connections"&gt;512&lt;/limit&gt;
>-</literallayout> 
>-
>-
>-<para>The name attribute is mandatory.
>-Available limit names are:</para>
>-<literallayout remap='.nf'>
>-      "max_incoming_bytes"         : total size in bytes of messages
>-                                     incoming from a single connection
>-      "max_outgoing_bytes"         : total size in bytes of messages
>-                                     queued up for a single connection
>-      "max_message_size"           : max size of a single message in
>-                                     bytes
>-      "service_start_timeout"      : milliseconds (thousandths) until 
>-                                     a started service has to connect
>-      "auth_timeout"               : milliseconds (thousandths) a
>-                                     connection is given to
>-                                     authenticate
>-      "max_completed_connections"  : max number of authenticated connections  
>-      "max_incomplete_connections" : max number of unauthenticated
>-                                     connections
>-      "max_connections_per_user"   : max number of completed connections from
>-                                     the same user
>-      "max_pending_service_starts" : max number of service launches in
>-                                     progress at the same time
>-      "max_names_per_connection"   : max number of names a single 
>-                                     connection can own
>-      "max_match_rules_per_connection": max number of match rules for a single 
>-                                        connection
>-      "max_replies_per_connection" : max number of pending method 
>-                                     replies per connection
>-                                     (number of calls-in-progress)
>-      "reply_timeout"              : milliseconds (thousandths) 
>-                                     until a method call times out   
>-</literallayout> 
>-
>-
>-<para>The max incoming/outgoing queue sizes allow a new message to be queued
>-if one byte remains below the max. So you can in fact exceed the max
>-by max_message_size.</para>
>-
>-
>-<para>max_completed_connections divided by max_connections_per_user is the
>-number of users that can work together to denial-of-service all other users by using
>-up all connections on the systemwide bus.</para>
>-
>-
>-<para>Limits are normally only of interest on the systemwide bus, not the user session 
>-buses.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;policy&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>The &lt;policy&gt; element defines a security policy to be applied to a particular
>-set of connections to the bus. A policy is made up of
>-&lt;allow&gt; and &lt;deny&gt; elements. Policies are normally used with the systemwide bus;
>-they are analogous to a firewall in that they allow expected traffic 
>-and prevent unexpected traffic.</para>
>-
>-
>-<para>The &lt;policy&gt; element has one of three attributes:</para>
>-<literallayout remap='.nf'>
>-  context="(default|mandatory)"
>-  user="username or userid"
>-  group="group name or gid"
>-</literallayout> 
>-
>-
>-<para> 
>-Policies are applied to a connection as follows:</para>
>-<literallayout remap='.nf'>
>-   - all context="default" policies are applied
>-   - all group="connection's user's group" policies are applied
>-     in undefined order
>-   - all user="connection's auth user" policies are applied
>-     in undefined order
>-   - all context="mandatory" policies are applied
>-</literallayout> 
>-
>-
>-<para>Policies applied later will override those applied earlier, 
>-when the policies overlap. Multiple policies with the same 
>-user/group/context are applied in the order they appear 
>-in the config file.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;deny&gt;</emphasis></term>
>-  <listitem>
>-<para><emphasis remap='I'>&lt;allow&gt;</emphasis></para>
>-
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>A &lt;deny&gt; element appears below a &lt;policy&gt; element and prohibits some
>-action. The &lt;allow&gt; element makes an exception to previous &lt;deny&gt;
>-statements, and works just like &lt;deny&gt; but with the inverse meaning.</para>
>-
>-
>-<para>The possible attributes of these elements are:</para>
>-<literallayout remap='.nf'>
>-   send_interface="interface_name"
>-   send_member="method_or_signal_name" 
>-   send_error="error_name" 
>-   send_destination="name" 
>-   send_type="method_call" | "method_return" | "signal" | "error" 
>-   send_path="/path/name"
>-
>-   receive_interface="interface_name"
>-   receive_member="method_or_signal_name" 
>-   receive_error="error_name" 
>-   receive_sender="name" 
>-   receive_type="method_call" | "method_return" | "signal" | "error"
>-   receive_path="/path/name"
>-
>-   send_requested_reply="true" | "false"
>-   receive_requested_reply="true" | "false"
>-
>-   eavesdrop="true" | "false"
>-
>-   own="name"
>-   own_prefix="name"
>-   user="username"
>-   group="groupname"
>-</literallayout> 
>-
>-
>-<para>Examples:</para>
>-<literallayout remap='.nf'>
>-   &lt;deny send_interface="org.freedesktop.System" send_member="Reboot"/&gt; 
>-   &lt;deny receive_interface="org.freedesktop.System" receive_member="Reboot"/&gt;
>-   &lt;deny own="org.freedesktop.System"/&gt;
>-   &lt;deny send_destination="org.freedesktop.System"/&gt;
>-   &lt;deny receive_sender="org.freedesktop.System"/&gt;
>-   &lt;deny user="john"/&gt;
>-   &lt;deny group="enemies"/&gt;
>-</literallayout> 
>-
>-
>-<para>The &lt;deny&gt; element's attributes determine whether the deny "matches" a
>-particular action. If it matches, the action is denied (unless later
>-rules in the config file allow it).</para>
>-
>-
>-<para>send_destination and receive_sender rules mean that messages may not be
>-sent to or received from the *owner* of the given name, not that
>-they may not be sent *to that name*. That is, if a connection
>-owns services A, B, C, and sending to A is denied, sending to B or C
>-will not work either.</para>
>-
>-
>-<para>The other send_* and receive_* attributes are purely textual/by-value
>-matches against the given field in the message header.</para>
>-
>-
>-<para>"Eavesdropping" occurs when an application receives a message that
>-was explicitly addressed to a name the application does not own.
>-Eavesdropping thus only applies to messages that are addressed to
>-services (i.e. it does not apply to signals).</para>
>-
>-
>-<para>For &lt;allow&gt;, eavesdrop="true" indicates that the rule matches even 
>-when eavesdropping. eavesdrop="false" is the default and means that 
>-the rule only allows messages to go to their specified recipient.
>-For &lt;deny&gt;, eavesdrop="true" indicates that the rule matches 
>-only when eavesdropping. eavesdrop="false" is the default for &lt;deny&gt;
>-also, but here it means that the rule applies always, even when 
>-not eavesdropping. The eavesdrop attribute can only be combined with
>-receive rules (with receive_* attributes).</para>
>-
>-
>-
>-<para>The [send|receive]_requested_reply attribute works similarly to the eavesdrop
>-attribute. It controls whether the &lt;deny&gt; or &lt;allow&gt; matches a reply
>-that is expected (corresponds to a previous method call message).
>-This attribute only makes sense for reply messages (errors and method
>-returns), and is ignored for other message types.</para>
>-
>-
>-<para>For &lt;allow&gt;, [send|receive]_requested_reply="true" is the default and indicates that
>-only requested replies are allowed by the
>-rule. [send|receive]_requested_reply="false" means that the rule allows any reply
>-even if unexpected.</para>
>-
>-
>-<para>For &lt;deny&gt;, [send|receive]_requested_reply="false" is the default but indicates that
>-the rule matches only when the reply was not
>-requested. [send|receive]_requested_reply="true" indicates that the rule applies
>-always, regardless of pending reply state.</para>
>-
>-
>-<para>user and group denials mean that the given user or group may 
>-not connect to the message bus.</para>
>-
>-
>-<para>For "name", "username", "groupname", etc.
>-the character "*" can be substituted, meaning "any." Complex globs
>-like "foo.bar.*" aren't allowed for now because they'd be work to
>-implement and maybe encourage sloppy security anyway.</para>
>-
>-<para>&lt;allow own_prefix="a.b"/&gt; allows you to own the name "a.b" or any
>-name whose first dot-separated elements are "a.b": in particular,
>-you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c".
>-This is useful when services like Telepathy and ReserveDevice
>-define a meaning for subtrees of well-known names, such as
>-org.freedesktop.Telepathy.ConnectionManager.(anything)
>-and org.freedesktop.ReserveDevice1.(anything).</para>
>-
>-<para>It does not make sense to deny a user or group inside a &lt;policy&gt;
>-for a user or group; user/group denials can only be inside
>-context="default" or context="mandatory" policies.</para>
>-
>-
>-<para>A single &lt;deny&gt; rule may specify combinations of attributes such as
>-send_destination and send_interface and send_type. In this case, the
>-denial applies only if both attributes match the message being denied.
>-e.g. &lt;deny send_interface="foo.bar" send_destination="foo.blah"/&gt; would
>-deny messages with the given interface AND the given bus name.
>-To get an OR effect you specify multiple &lt;deny&gt; rules.</para>
>-
>-
>-<para>You can't include both send_ and receive_ attributes on the same
>-rule, since "whether the message can be sent" and "whether it can be
>-received" are evaluated separately.</para>
>-
>-
>-<para>Be careful with send_interface/receive_interface, because the 
>-interface field in messages is optional.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;selinux&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>The &lt;selinux&gt; element contains settings related to Security Enhanced Linux.
>-More details below.</para>
>-
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><emphasis remap='I'>&lt;associate&gt;</emphasis></term>
>-  <listitem>
>-
>-<para></para> 
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-
>-<para>An &lt;associate&gt; element appears below an &lt;selinux&gt; element and
>-creates a mapping. Right now only one kind of association is possible:</para>
>-<literallayout remap='.nf'>
>-   &lt;associate own="org.freedesktop.Foobar" context="foo_t"/&gt; 
>-</literallayout> 
>-
>-
>-<para>This means that if a connection asks to own the name
>-"org.freedesktop.Foobar" then the source context will be the context
>-of the connection and the target context will be "foo_t" - see the 
>-short discussion of SELinux below.</para>
>-
>-
>-<para>Note, the context here is the target context when requesting a name,
>-NOT the context of the connection owning the name.</para>
>-
>-
>-<para>There's currently no way to set a default for owning any name, if
>-we add this syntax it will look like:</para>
>-<literallayout remap='.nf'>
>-   &lt;associate own="*" context="foo_t"/&gt; 
>-</literallayout> 
>-<para>If you find a reason this is useful, let the developers know.
>-Right now the default will be the security context of the bus itself.</para>
>-
>-
>-<para>If two &lt;associate&gt; elements specify the same name, the element
>-appearing later in the configuration file will be used.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='selinux'><title>SELinux</title>
>-<para>See <ulink url='http://www.nsa.gov/selinux/'>http://www.nsa.gov/selinux/</ulink> for full details on SELinux. Some useful excerpts:</para>
>-
>-
>-<para>Every subject (process) and object (e.g. file, socket, IPC object,
>-etc) in the system is assigned a collection of security attributes,
>-known as a security context. A security context contains all of the
>-security attributes associated with a particular subject or object
>-that are relevant to the security policy.</para>
>-
>-
>-<para>In order to better encapsulate security contexts and to provide
>-greater efficiency, the policy enforcement code of SELinux typically
>-handles security identifiers (SIDs) rather than security contexts. A
>-SID is an integer that is mapped by the security server to a security
>-context at runtime.</para>
>-
>-
>-<para>When a security decision is required, the policy enforcement code
>-passes a pair of SIDs (typically the SID of a subject and the SID of
>-an object, but sometimes a pair of subject SIDs or a pair of object
>-SIDs), and an object security class to the security server. The object
>-security class indicates the kind of object, e.g. a process, a regular
>-file, a directory, a TCP socket, etc.</para>
>-
>-
>-<para>Access decisions specify whether or not a permission is granted for a
>-given pair of SIDs and class. Each object class has a set of
>-associated permissions defined to control operations on objects with
>-that class.</para>
>-
>-
>-<para>D-Bus performs SELinux security checks in two places.</para>
>-
>-
>-<para>First, any time a message is routed from one connection to another
>-connection, the bus daemon will check permissions with the security context of
>-the first connection as source, security context of the second connection
>-as target, object class "dbus" and requested permission "send_msg".</para>
>-
>-
>-<para>If a security context is not available for a connection 
>-(impossible when using UNIX domain sockets), then the target 
>-context used is the context of the bus daemon itself.
>-There is currently no way to change this default, because we're 
>-assuming that only UNIX domain sockets will be used to 
>-connect to the systemwide bus. If this changes, we'll 
>-probably add a way to set the default connection context.</para>
>-
>-
>-<para>Second, any time a connection asks to own a name, 
>-the bus daemon will check permissions with the security 
>-context of the connection as source, the security context specified
>-for the name in the config file as target, object 
>-class "dbus" and requested permission "acquire_svc".</para>
>-
>-
>-<para>The security context for a bus name is specified with the 
>-&lt;associate&gt; element described earlier in this document.
>-If a name has no security context associated in the 
>-configuration file, the security context of the bus daemon 
>-itself will be used.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='author'><title>AUTHOR</title>
>-<para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para>
>-
>-</refsect1>
>-
>-<refsect1 id='bugs'><title>BUGS</title>
>-<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>-see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>-</refsect1>
>-</refentry>
>-
>diff --git a/cmake/doc/CMakeLists.txt b/cmake/doc/CMakeLists.txt
>index e107918..8bceded 100644
>--- a/cmake/doc/CMakeLists.txt
>+++ b/cmake/doc/CMakeLists.txt
>@@ -96,10 +96,11 @@ DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-test-plan.xml html-nochunks)
> DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-tutorial.xml html-nochunks)
> DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-specification.xml html-nochunks)
> DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-faq.xml html-nochunks)
>-DOCBOOK(${CMAKE_SOURCE_DIR}/bus/dbus-daemon.xml html-nochunks)
>-DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-monitor.xml html-nochunks)
>-DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-send.xml html-nochunks)
>-DOCBOOK(${CMAKE_SOURCE_DIR}/tools/dbus-launch.xml html-nochunks)
>+configure_file(${CMAKE_SOURCE_DIR}/../doc/dbus-daemon.1.xml.in ${CMAKE_BINARY_DIR}/doc/dbus-daemon.1.xml)
>+DOCBOOK(${CMAKE_BINARY_DIR}/doc/dbus-daemon.1.xml html-nochunks)
>+DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-monitor.1.xml html-nochunks)
>+DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-send.1.xml html-nochunks)
>+DOCBOOK(${CMAKE_SOURCE_DIR}/../doc/dbus-launch.1.xml html-nochunks)
> 
> #
> # handle html index file
>diff --git a/cmake/tools/dbus-launch.xml b/cmake/tools/dbus-launch.xml
>deleted file mode 100644
>index dc34898..0000000
>--- a/cmake/tools/dbus-launch.xml
>+++ /dev/null
>@@ -1,240 +0,0 @@
>-<?xml version="1.0" encoding="ISO-8859-1"?>
>-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
>-                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
>-
>-<refentry id='dbuslaunch1'>
>-
>-
>-
>-
>-<refmeta>
>-<refentrytitle>dbus-launch</refentrytitle>
>-<manvolnum>1</manvolnum>
>-</refmeta>
>-<refnamediv id='name'>
>-<refname>dbus-launch</refname>
>-<refpurpose>Utility to start a message bus from a shell script</refpurpose>
>-</refnamediv>
>-
>-<refsynopsisdiv id='synopsis'>
>-<cmdsynopsis>
>-  <command>dbus-launch</command>    <arg choice='opt'>--version </arg>
>-    <arg choice='opt'>--sh-syntax </arg>
>-    <arg choice='opt'>--csh-syntax </arg>
>-    <arg choice='opt'>--auto-syntax </arg>
>-    <arg choice='opt'>--exit-with-session </arg>
>-    <arg choice='opt'>--autolaunch=<replaceable>MACHINEID</replaceable></arg>
>-    <arg choice='opt'>--config-file=<replaceable>FILENAME</replaceable></arg>
>-    <arg choice='opt'><replaceable>PROGRAM</replaceable></arg>
>-    <arg choice='opt' rep='repeat'><replaceable>ARGS</replaceable></arg>
>-    <sbr/>
>-</cmdsynopsis>
>-</refsynopsisdiv>
>-
>-
>-<refsect1 id='description'><title>DESCRIPTION</title>
>-<para>The <command>dbus-launch</command> command is used to start a session bus 
>-instance of <emphasis remap='I'>dbus-daemon</emphasis> from a shell script.
>-It would normally be called from a user's login
>-scripts. Unlike the daemon itself, <command>dbus-launch</command> exits, so
>-backticks or the $() construct can be used to read information from
>-<command>dbus-launch</command>.</para>
>-
>-<para>With no arguments, <command>dbus-launch</command> will launch a session bus
>-instance and print the address and pid of that instance to standard
>-output.</para>
>-
>-<para>You may specify a program to be run; in this case, <command>dbus-launch</command>
>-will launch a session bus instance, set the appropriate environment
>-variables so the specified program can find the bus, and then execute the
>-specified program, with the specified arguments.  See below for
>-examples.</para>
>-
>-<para>If you launch a program, <command>dbus-launch</command> will not print the
>-information about the new bus to standard output.</para>
>-
>-<para>When <command>dbus-launch</command> prints bus information to standard output, by
>-default it is in a simple key-value pairs format. However, you may 
>-request several alternate syntaxes using the --sh-syntax, --csh-syntax,
>---binary-syntax, or
>---auto-syntax options. Several of these cause <command>dbus-launch</command> to emit shell code
>-to set up the environment.</para>
>-
>-<para>With the --auto-syntax option, <command>dbus-launch</command> looks at the value
>-of the SHELL environment variable to determine which shell syntax
>-should be used.  If SHELL ends in "csh", then csh-compatible code is
>-emitted; otherwise Bourne shell code is emitted.  Instead of passing
>---auto-syntax, you may explicity specify a particular one by using
>---sh-syntax for Bourne syntax, or --csh-syntax for csh syntax.
>-In scripts, it's more robust to avoid --auto-syntax and you hopefully
>-know which shell your script is written in.</para>
>-
>-
>-<para>See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information
>-about D-Bus. See also the man page for <emphasis remap='I'>dbus-daemon</emphasis>.</para>
>-
>-
>-<para>Here is an example of how to use <command>dbus-launch</command> with an 
>-sh-compatible shell to start the per-session bus daemon:</para>
>-<literallayout remap='.nf'>
>-
>-  ## test for an existing bus daemon, just to be safe
>-  if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
>-      ## if not found, launch a new one
>-      eval `dbus-launch --sh-syntax --exit-with-session`
>-      echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS"
>-  fi
>-
>-</literallayout> 
>-<para>You might run something like that in your login scripts.</para>
>-
>-
>-<para>Another way to use <command>dbus-launch</command> is to run your main session
>-program, like so:</para>
>-<literallayout remap='.nf'>
>-
>-dbus-launch gnome-session
>-
>-</literallayout> 
>-<para>The above would likely be appropriate for ~/.xsession or ~/.Xclients.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='automatic_launching'><title>AUTOMATIC LAUNCHING</title>
>-<para>If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use
>-D-Bus, by default the process will attempt to invoke dbus-launch with
>-the --autolaunch option to start up a new session bus or find the 
>-existing bus address on the X display or in a file in
>-~/.dbus/session-bus/</para>
>-
>-
>-<para>Whenever an autolaunch occurs, the application that had to
>-start a new bus will be in its own little world; it can effectively
>-end up starting a whole new session if it tries to use a lot of 
>-bus services. This can be suboptimal or even totally broken, depending
>-on the app and what it tries to do.</para>
>-
>-
>-<para>There are two common reasons for autolaunch. One is ssh to a remote
>-machine. The ideal fix for that would be forwarding of
>-DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded.
>-In the meantime, you can edit the session.conf config file to 
>-have your session bus listen on TCP, and manually set
>-DBUS_SESSION_BUS_ADDRESS, if you like.</para>
>-
>-
>-<para>The second common reason for autolaunch is an su to another user, and
>-display of X applications running as the second user on the display
>-belonging to the first user. Perhaps the ideal fix in this case
>-would be to allow the second user to connect to the session bus of the
>-first user, just as they can connect to the first user's display.
>-However, a mechanism for that has not been coded.</para>
>-
>-
>-<para>You can always avoid autolaunch by manually setting
>-DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
>-address if none is set is "autolaunch:", so if any other address is
>-set there will be no autolaunch. You can however include autolaunch in
>-an explicit session bus address as a fallback, for example
>-DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
>-the first address doesn't work, processes will autolaunch. (The bus
>-address variable contains a comma-separated list of addresses to try.)</para>
>-
>-
>-<para>The --autolaunch option is considered an internal implementation
>-detail of libdbus, and in fact there are plans to change it. There's
>-no real reason to use it outside of the libdbus implementation anyhow.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='options'><title>OPTIONS</title>
>-<para>The following options are supported:</para>
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><option>--auto-syntax</option></term>
>-  <listitem>
>-<para>Choose --csh-syntax or --sh-syntax based on the SHELL environment variable.</para>
>-
>-<para><option>--binary-syntax</option>
>-Write to stdout a nul-terminated bus address, then the bus PID as a
>-binary integer of size sizeof(pid_t), then the bus X window ID as a
>-binary integer of size sizeof(long). Integers are in the machine's
>-byte order, not network byte order or any other canonical byte order.</para>
>-
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--close-stderr</option></term>
>-  <listitem>
>-<para>Close the standard error output stream before starting the D-Bus
>-daemon. This is useful if you want to capture dbus-launch error
>-messages but you don't want dbus-daemon to keep the stream open to
>-your application.</para>
>-
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--config-file=FILENAME</option></term>
>-  <listitem>
>-<para>Pass --config-file=FILENAME to the bus daemon, instead of passing it 
>-the --session argument. See the man page for dbus-daemon</para>
>-
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--csh-syntax</option></term>
>-  <listitem>
>-<para>Emit csh compatible code to set up environment variables.</para>
>-
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--exit-with-session</option></term>
>-  <listitem>
>-<para>If this option is provided, a persistent "babysitter" process will be 
>-created that watches stdin for HUP and tries to connect to the X
>-server. If this process gets a HUP on stdin or loses its X connection,
>-it kills the message bus daemon.</para>
>-
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--autolaunch=MACHINEID</option></term>
>-  <listitem>
>-<para>This option implies that <command>dbus-launch</command> should scan for a
>-previously-started session and reuse the values found there. If no
>-session is found, it will start a new session. The
>---exit-with-session option is implied if --autolaunch is given.
>-This option is for the exclusive use of libdbus, you do not want to
>-use it manually. It may change in the future.</para>
>-
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--sh-syntax</option></term>
>-  <listitem>
>-<para>Emit Bourne-shell compatible code to set up environment variables.</para>
>-
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--version</option></term>
>-  <listitem>
>-<para>Print the version of dbus-launch</para>
>-
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-</refsect1>
>-
>-<refsect1 id='author'><title>AUTHOR</title>
>-<para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para>
>-
>-</refsect1>
>-
>-<refsect1 id='bugs'><title>BUGS</title>
>-<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>-see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>-</refsect1>
>-</refentry>
>-
>diff --git a/cmake/tools/dbus-monitor.xml b/cmake/tools/dbus-monitor.xml
>deleted file mode 100644
>index b41cace..0000000
>--- a/cmake/tools/dbus-monitor.xml
>+++ /dev/null
>@@ -1,121 +0,0 @@
>-<?xml version="1.0" encoding="ISO-8859-1"?>
>-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
>-                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
>-
>-<refentry id='dbusmonitor1'>
>-
>-
>-
>-
>-<refmeta>
>-<refentrytitle>dbus-monitor</refentrytitle>
>-<manvolnum>1</manvolnum>
>-</refmeta>
>-<refnamediv id='name'>
>-<refname>dbus-monitor</refname>
>-<refpurpose>debug probe to print message bus messages</refpurpose>
>-</refnamediv>
>-
>-<refsynopsisdiv id='synopsis'>
>-<cmdsynopsis>
>-  <command>dbus-monitor</command>    
>-    <group choice='opt'><arg choice='plain'>--system </arg><arg choice='plain'>--session </arg><arg choice='plain'>--address <replaceable>ADDRESS</replaceable></arg></group>
>-    <group choice='opt'><arg choice='plain'>--profile </arg><arg choice='plain'>--monitor </arg></group>
>-    <arg choice='opt'><arg choice='plain'><replaceable>watch</replaceable></arg><arg choice='plain'><replaceable>expressions</replaceable></arg></arg>
>-    <sbr/>
>-</cmdsynopsis>
>-</refsynopsisdiv>
>-
>-
>-<refsect1 id='description'><title>DESCRIPTION</title>
>-<para>The <command>dbus-monitor</command> command is used to monitor messages going
>-through a D-Bus message bus.  See
>-<ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about
>-the big picture.</para>
>-
>-
>-<para>There are two well-known message buses: the systemwide message bus
>-(installed on many systems as the "messagebus" service) and the
>-per-user-login-session message bus (started each time a user logs in).
>-The --system and --session options direct <command>dbus-monitor</command> to
>-monitor the system or session buses respectively.  If neither is
>-specified, <command>dbus-monitor</command> monitors the session bus.</para>
>-
>-
>-<para><command>dbus-monitor</command> has two different output modes, the 'classic'-style
>-monitoring mode and profiling mode. The profiling format is a compact
>-format with a single line per message and microsecond-resolution timing
>-information. The --profile and --monitor options select the profiling
>-and monitoring output format respectively. If neither is specified,
>-<command>dbus-monitor</command> uses the monitoring output format.</para>
>-
>-
>-<para>In order to get <command>dbus-monitor</command> to see the messages you are interested
>-in, you should specify a set of watch expressions as you would expect to
>-be passed to the <emphasis remap='I'>dbus_bus_add_match</emphasis> function.</para>
>-
>-
>-<para>The message bus configuration may keep <command>dbus-monitor</command> from seeing
>-all messages, especially if you run the monitor as a non-root user.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='options'><title>OPTIONS</title>
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><option>--system</option></term>
>-  <listitem>
>-<para>Monitor the system message bus.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--session</option></term>
>-  <listitem>
>-<para>Monitor the session message bus.  (This is the default.)</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--address ADDRESS</option></term>
>-  <listitem>
>-<para>Monitor an arbitrary message bus given at ADDRESS.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--profile</option></term>
>-  <listitem>
>-<para>Use the profiling output format.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--monitor</option></term>
>-  <listitem>
>-<para>Use the monitoring output format.  (This is the default.)</para>
>-
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-</refsect1>
>-
>-<refsect1 id='example'><title>EXAMPLE</title>
>-<para>Here is an example of using dbus-monitor to watch for the gnome typing
>-monitor to say things</para>
>-<literallayout remap='.nf'>
>-
>-  dbus-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'"
>-
>-</literallayout> 
>-
>-</refsect1>
>-
>-<refsect1 id='author'><title>AUTHOR</title>
>-<para>dbus-monitor was written by Philip Blundell.
>-The profiling output mode was added by Olli Salli.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='bugs'><title>BUGS</title>
>-<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>-see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>-</refsect1>
>-</refentry>
>-
>diff --git a/cmake/tools/dbus-send.xml b/cmake/tools/dbus-send.xml
>deleted file mode 100644
>index 7fefc03..0000000
>--- a/cmake/tools/dbus-send.xml
>+++ /dev/null
>@@ -1,143 +0,0 @@
>-<?xml version="1.0" encoding="ISO-8859-1"?>
>-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
>-                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
>-
>-<refentry id='dbussend1'>
>-
>-
>-
>-
>-<refmeta>
>-<refentrytitle>dbus-send</refentrytitle>
>-<manvolnum>1</manvolnum>
>-</refmeta>
>-<refnamediv id='name'>
>-<refname>dbus-send</refname>
>-<refpurpose>Send a message to a message bus</refpurpose>
>-</refnamediv>
>-
>-<refsynopsisdiv id='synopsis'>
>-<cmdsynopsis>
>-  <command>dbus-send</command>    
>-    <group choice='opt'><arg choice='plain'>--system </arg><arg choice='plain'>--session </arg></group>
>-    <arg choice='opt'>--dest=<replaceable>NAME</replaceable></arg>
>-    <arg choice='opt'>--print-reply </arg>
>-    <arg choice='opt'>--type=<replaceable>TYPE</replaceable></arg>
>-    <arg choice='plain'><replaceable>&lt;destination</replaceable></arg>
>-    <arg choice='plain'><replaceable>object</replaceable></arg>
>-    <arg choice='plain'><replaceable>path&gt;</replaceable></arg>
>-    <arg choice='plain'><replaceable>&lt;message</replaceable></arg>
>-    <arg choice='plain'><replaceable>name&gt;</replaceable></arg>
>-    <arg choice='opt' rep='repeat'><replaceable>contents</replaceable></arg>
>-    <sbr/>
>-</cmdsynopsis>
>-</refsynopsisdiv>
>-
>-
>-<refsect1 id='description'><title>DESCRIPTION</title>
>-<para>The <command>dbus-send</command> command is used to send a message to a D-Bus message
>-bus. See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more 
>-information about the big picture.</para>
>-
>-
>-<para>There are two well-known message buses: the systemwide message bus 
>-(installed on many systems as the "messagebus" service) and the 
>-per-user-login-session message bus (started each time a user logs in).
>-The --system and --session options direct <command>dbus-send</command> to send
>-messages to the system or session buses respectively.  If neither is
>-specified, <command>dbus-send</command> sends to the session bus.</para>
>-
>-
>-<para>Nearly all uses of <command>dbus-send</command> must provide the --dest argument
>-which is the name of a connection on the bus to send the message to. If
>---dest is omitted, no destination is set.</para>
>-
>-
>-<para>The object path and the name of the message to send must always be
>-specified. Following arguments, if any, are the message contents
>-(message arguments).  These are given as type-specified values and 
>-may include containers (arrays, dicts, and variants) as described below.</para>
>-
>-<literallayout remap='.nf'>
>-&lt;contents&gt;   ::= &lt;item&gt; | &lt;container&gt; [ &lt;item&gt; | &lt;container&gt;...]
>-&lt;item&gt;       ::= &lt;type&gt;:&lt;value&gt;
>-&lt;container&gt;  ::= &lt;array&gt; | &lt;dict&gt; | &lt;variant&gt;
>-&lt;array&gt;      ::= array:&lt;type&gt;:&lt;value&gt;[,&lt;value&gt;...] 
>-&lt;dict&gt;       ::= dict:&lt;type&gt;:&lt;type&gt;:&lt;key&gt;,&lt;value&gt;[,&lt;key&gt;,&lt;value&gt;...]
>-&lt;variant&gt;    ::= variant:&lt;type&gt;:&lt;value&gt;
>-&lt;type&gt;       ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath
>-</literallayout> 
>-
>-<para>D-Bus supports more types than these, but <command>dbus-send</command> currently
>-does not.  Also, <command>dbus-send</command> does not permit empty containers
>-or nested containers (e.g. arrays of variants).</para>
>-
>-
>-<para>Here is an example invocation:</para>
>-<literallayout remap='.nf'>
>-
>-  dbus-send --dest=org.freedesktop.ExampleName               \
>-            /org/freedesktop/sample/object/name              \
>-            org.freedesktop.ExampleInterface.ExampleMethod   \
>-            int32:47 string:'hello world' double:65.32       \
>-            array:string:"1st item","next item","last item"  \
>-            dict:string:int32:"one",1,"two",2,"three",3      \
>-            variant:int32:-8                                 \
>-            objpath:/org/freedesktop/sample/object/name 
>-
>-</literallayout> 
>-
>-<para>Note that the interface is separated from a method or signal 
>-name by a dot, though in the actual protocol the interface
>-and the interface member are separate fields.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='options'><title>OPTIONS</title>
>-<para>The following options are supported:</para>
>-<variablelist remap='TP'>
>-  <varlistentry>
>-  <term><option>--dest=NAME</option></term>
>-  <listitem>
>-<para>Specify the name of the connection to receive the message.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--print-reply</option></term>
>-  <listitem>
>-<para>Block for a reply to the message sent, and print any reply received.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--system</option></term>
>-  <listitem>
>-<para>Send to the system message bus.</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--session</option></term>
>-  <listitem>
>-<para>Send to the session message bus.  (This is the default.)</para>
>-  </listitem>
>-  </varlistentry>
>-  <varlistentry>
>-  <term><option>--type=TYPE</option></term>
>-  <listitem>
>-<para>Specify "method_call" or "signal" (defaults to "signal").</para>
>-
>-  </listitem>
>-  </varlistentry>
>-</variablelist>
>-</refsect1>
>-
>-<refsect1 id='author'><title>AUTHOR</title>
>-<para>dbus-send was written by Philip Blundell.</para>
>-
>-</refsect1>
>-
>-<refsect1 id='bugs'><title>BUGS</title>
>-<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>-see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>-</refsect1>
>-</refentry>
>-
>diff --git a/doc/dbus-daemon.1.xml.in b/doc/dbus-daemon.1.xml.in
>new file mode 100644
>index 0000000..bc602bb
>--- /dev/null
>+++ b/doc/dbus-daemon.1.xml.in
>@@ -0,0 +1,888 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
>+
>+<refentry id='dbusdaemon1in'>
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-daemon</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv>
>+<refname>dbus-daemon</refname>
>+<refpurpose>Message bus daemon</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-daemon</command></cmdsynopsis>
>+<cmdsynopsis>
>+  <command>dbus-daemon</command>    <arg choice='opt'>--version </arg>
>+    <arg choice='opt'>--session </arg>
>+    <arg choice='opt'>--system </arg>
>+    <arg choice='opt'>--config-file=<replaceable>FILE</replaceable></arg>
>+    <arg choice='opt'><arg choice='plain'>--print-address </arg><arg choice='opt'><replaceable>=DESCRIPTOR</replaceable></arg></arg>
>+    <arg choice='opt'><arg choice='plain'>--print-pid </arg><arg choice='opt'><replaceable>=DESCRIPTOR</replaceable></arg></arg>
>+    <arg choice='opt'>--fork </arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para><command>dbus-daemon</command> is the D-Bus message bus daemon. See
>+<ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about
>+the big picture. D-Bus is first a library that provides one-to-one
>+communication between any two applications; <command>dbus-daemon</command> is an
>+application that uses this library to implement a message bus
>+daemon. Multiple programs connect to the message bus daemon and can
>+exchange messages with one another.</para>
>+
>+<para>There are two standard message bus instances: the systemwide message bus
>+(installed on many systems as the "messagebus" init service) and the
>+per-user-login-session message bus (started each time a user logs in).
>+<command>dbus-daemon</command> is used for both of these instances, but with
>+a different configuration file.</para>
>+
>+<para>The --session option is equivalent to
>+"--config-file=@EXPANDED_SYSCONFDIR@/dbus-1/session.conf" and the --system
>+option is equivalent to
>+"--config-file=@EXPANDED_SYSCONFDIR@/dbus-1/system.conf". By creating
>+additional configuration files and using the --config-file option,
>+additional special-purpose message bus daemons could be created.</para>
>+
>+<para>The systemwide daemon is normally launched by an init script,
>+standardly called simply "messagebus".</para>
>+
>+<para>The systemwide daemon is largely used for broadcasting system events,
>+such as changes to the printer queue, or adding/removing devices.</para>
>+
>+<para>The per-session daemon is used for various interprocess communication
>+among desktop applications (however, it is not tied to X or the GUI
>+in any way).</para>
>+
>+<para>SIGHUP will cause the D-Bus daemon to PARTIALLY reload its
>+configuration file and to flush its user/group information caches. Some
>+configuration changes would require kicking all apps off the bus; so they will
>+only take effect if you restart the daemon. Policy changes should take effect
>+with SIGHUP.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<para>The following options are supported:</para>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--config-file=FILE</option></term>
>+  <listitem>
>+<para>Use the given configuration file.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--fork</option></term>
>+  <listitem>
>+<para>Force the message bus to fork and become a daemon, even if
>+the configuration file does not specify that it should.
>+In most contexts the configuration file already gets this
>+right, though.
>+<option>--nofork</option>
>+Force the message bus not to fork and become a daemon, even if
>+the configuration file specifies that it should.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--print-address[=DESCRIPTOR]</option></term>
>+  <listitem>
>+<para>Print the address of the message bus to standard output, or
>+to the given file descriptor. This is used by programs that
>+launch the message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--print-pid[=DESCRIPTOR]</option></term>
>+  <listitem>
>+<para>Print the process ID of the message bus to standard output, or
>+to the given file descriptor. This is used by programs that
>+launch the message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--session</option></term>
>+  <listitem>
>+<para>Use the standard configuration file for the per-login-session message
>+bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--system</option></term>
>+  <listitem>
>+<para>Use the standard configuration file for the systemwide message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--version</option></term>
>+  <listitem>
>+<para>Print the version of the daemon.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--introspect</option></term>
>+  <listitem>
>+<para>Print the introspection information for all D-Bus internal interfaces.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--address[=ADDRESS]</option></term>
>+  <listitem>
>+<para>Set the address to listen on. This option overrides the address
>+configured in the configuration file.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--systemd-activation</option></term>
>+  <listitem>
>+<para>Enable systemd-style service activation. Only useful in conjunction
>+with the systemd system and session manager on Linux.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--nopidfile</option></term>
>+  <listitem>
>+<para>Don't write a PID file even if one is configured in the configuration
>+files.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='configuration_file'><title>CONFIGURATION FILE</title>
>+<para>A message bus daemon has a configuration file that specializes it
>+for a particular application. For example, one configuration
>+file might set up the message bus to be a systemwide message bus,
>+while another might set it up to be a per-user-login-session bus.</para>
>+
>+<para>The configuration file also establishes resource limits, security
>+parameters, and so forth.</para>
>+
>+<para>The configuration file is not part of any interoperability
>+specification and its backward compatibility is not guaranteed; this
>+document is documentation, not specification.</para>
>+
>+<para>The standard systemwide and per-session message bus setups are
>+configured in the files "@EXPANDED_SYSCONFDIR@/dbus-1/system.conf" and
>+"@EXPANDED_SYSCONFDIR@/dbus-1/session.conf".  These files normally
>+&lt;include&gt; a system-local.conf or session-local.conf; you can put local
>+overrides in those files to avoid modifying the primary configuration
>+files.</para>
>+
>+
>+<para>The configuration file is an XML document. It must have the following
>+doctype declaration:</para>
>+<literallayout remap='.nf'>
>+
>+   &lt;!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
>+    "<ulink url='http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd'>http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd</ulink>"&gt;
>+
>+</literallayout> 
>+
>+
>+<para>The following elements may be present in the configuration file.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;busconfig&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>Root element.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;type&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>The well-known type of the message bus. Currently known values are
>+"system" and "session"; if other values are set, they should be
>+either added to the D-Bus specification, or namespaced.  The last
>+&lt;type&gt; element "wins" (previous values are ignored). This element
>+only controls which message bus specific environment variables are
>+set in activated clients.  Most of the policy that distinguishes a
>+session bus from the system bus is controlled from the other elements
>+in the configuration file.</para>
>+
>+
>+<para>If the well-known type of the message bus is "session", then the
>+DBUS_STARTER_BUS_TYPE environment variable will be set to "session"
>+and the DBUS_SESSION_BUS_ADDRESS environment variable will be set
>+to the address of the session bus.  Likewise, if the type of the
>+message bus is "system", then the DBUS_STARTER_BUS_TYPE environment
>+variable will be set to "system" and the DBUS_SESSION_BUS_ADDRESS
>+environment variable will be set to the address of the system bus
>+(which is normally well known anyway).</para>
>+
>+
>+<para>Example: &lt;type&gt;session&lt;/type&gt;</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;include&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>Include a file &lt;include&gt;filename.conf&lt;/include&gt; at this point.  If the
>+filename is relative, it is located relative to the configuration file
>+doing the including.</para>
>+
>+
>+<para>&lt;include&gt; has an optional attribute "ignore_missing=(yes|no)"
>+which defaults to "no" if not provided. This attribute
>+controls whether it's a fatal error for the included file
>+to be absent.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;includedir&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>Include all files in &lt;includedir&gt;foo.d&lt;/includedir&gt; at this
>+point. Files in the directory are included in undefined order.
>+Only files ending in ".conf" are included.</para>
>+
>+
>+<para>This is intended to allow extension of the system bus by particular
>+packages. For example, if CUPS wants to be able to send out
>+notification of printer queue changes, it could install a file to
>+@EXPANDED_SYSCONFDIR@/dbus-1/system.d that allowed all apps to receive
>+this message and allowed the printer daemon user to send it.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;user&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>The user account the daemon should run as, as either a username or a
>+UID. If the daemon cannot change to this UID on startup, it will exit.
>+If this element is not present, the daemon will not change or care
>+about its UID.</para>
>+
>+
>+<para>The last &lt;user&gt; entry in the file "wins", the others are ignored.</para>
>+
>+
>+<para>The user is changed after the bus has completed initialization.  So
>+sockets etc. will be created before changing user, but no data will be
>+read from clients before changing user. This means that sockets
>+and PID files can be created in a location that requires root
>+privileges for writing.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;fork&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>If present, the bus daemon becomes a real daemon (forks
>+into the background, etc.). This is generally used
>+rather than the --fork command line option.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;keep_umask&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>If present, the bus daemon keeps its original umask when forking.
>+This may be useful to avoid affecting the behavior of child processes.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;listen&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>Add an address that the bus should listen on. The
>+address is in the standard D-Bus format that contains
>+a transport name plus possible parameters/options.</para>
>+
>+
>+<para>Example: &lt;listen&gt;unix:path=/tmp/foo&lt;/listen&gt;</para>
>+
>+
>+<para>Example: &lt;listen&gt;tcp:host=localhost,port=1234&lt;/listen&gt;</para>
>+
>+
>+<para>If there are multiple &lt;listen&gt; elements, then the bus listens
>+on multiple addresses. The bus will pass its address to
>+started services or other interested parties with
>+the last address given in &lt;listen&gt; first. That is,
>+apps will try to connect to the last &lt;listen&gt; address first.</para>
>+
>+
>+<para>tcp sockets can accept IPv4 addresses, IPv6 addresses or hostnames.
>+If a hostname resolves to multiple addresses, the server will bind
>+to all of them. The family=ipv4 or family=ipv6 options can be used
>+to force it to bind to a subset of addresses</para>
>+
>+
>+<para>Example: &lt;listen&gt;tcp:host=localhost,port=0,family=ipv4&lt;/listen&gt;</para>
>+
>+
>+<para>A special case is using a port number of zero (or omitting the port),
>+which means to choose an available port selected by the operating
>+system. The port number chosen can be obtained with the
>+--print-address command line parameter and will be present in other
>+cases where the server reports its own address, such as when
>+DBUS_SESSION_BUS_ADDRESS is set.</para>
>+
>+
>+<para>Example: &lt;listen&gt;tcp:host=localhost,port=0&lt;/listen&gt;</para>
>+
>+
>+<para>tcp addresses also allow a bind=hostname option, which will override
>+the host option specifying what address to bind to, without changing
>+the address reported by the bus. The bind option can also take a
>+special name '*' to cause the bus to listen on all local address
>+(INADDR_ANY). The specified host should be a valid name of the local
>+machine or weird stuff will happen.</para>
>+
>+
>+<para>Example: &lt;listen&gt;tcp:host=localhost,bind=*,port=0&lt;/listen&gt;</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;auth&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>Lists permitted authorization mechanisms. If this element doesn't
>+exist, then all known mechanisms are allowed.  If there are multiple
>+&lt;auth&gt; elements, all the listed mechanisms are allowed.  The order in
>+which mechanisms are listed is not meaningful.</para>
>+
>+
>+<para>Example: &lt;auth&gt;EXTERNAL&lt;/auth&gt;</para>
>+
>+
>+<para>Example: &lt;auth&gt;DBUS_COOKIE_SHA1&lt;/auth&gt;</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;servicedir&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>Adds a directory to scan for .service files. Directories are
>+scanned starting with the last to appear in the config file
>+(the first .service file found that provides a particular
>+service will be used).</para>
>+
>+
>+<para>Service files tell the bus how to automatically start a program.
>+They are primarily used with the per-user-session bus,
>+not the systemwide bus.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;standard_session_servicedirs/&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>&lt;standard_session_servicedirs/&gt; is equivalent to specifying a series
>+of &lt;servicedir/&gt; elements for each of the data directories in the "XDG
>+Base Directory Specification" with the subdirectory "dbus-1/services",
>+so for example "/usr/share/dbus-1/services" would be among the
>+directories searched.</para>
>+
>+
>+<para>The "XDG Base Directory Specification" can be found at
>+<ulink url='http://freedesktop.org/wiki/Standards/basedir-spec'>http://freedesktop.org/wiki/Standards/basedir-spec</ulink> if it hasn't moved,
>+otherwise try your favorite search engine.</para>
>+
>+
>+<para>The &lt;standard_session_servicedirs/&gt; option is only relevant to the
>+per-user-session bus daemon defined in
>+@EXPANDED_SYSCONFDIR@/dbus-1/session.conf. Putting it in any other
>+configuration file would probably be nonsense.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;standard_system_servicedirs/&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>&lt;standard_system_servicedirs/&gt; specifies the standard system-wide
>+activation directories that should be searched for service files.
>+This option defaults to @EXPANDED_DATADIR@/dbus-1/system-services.</para>
>+
>+
>+<para>The &lt;standard_system_servicedirs/&gt; option is only relevant to the
>+per-system bus daemon defined in
>+@EXPANDED_SYSCONFDIR@/dbus-1/system.conf. Putting it in any other
>+configuration file would probably be nonsense.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;servicehelper/&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>&lt;servicehelper/&gt; specifies the setuid helper that is used to launch
>+system daemons with an alternate user. Typically this should be
>+the dbus-daemon-launch-helper executable in located in libexec.</para>
>+
>+
>+<para>The &lt;servicehelper/&gt; option is only relevant to the per-system bus daemon
>+defined in @EXPANDED_SYSCONFDIR@/dbus-1/system.conf. Putting it in any other
>+configuration file would probably be nonsense.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;limit&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>&lt;limit&gt; establishes a resource limit. For example:</para>
>+<literallayout remap='.nf'>
>+  &lt;limit name="max_message_size"&gt;64&lt;/limit&gt;
>+  &lt;limit name="max_completed_connections"&gt;512&lt;/limit&gt;
>+</literallayout> 
>+
>+
>+<para>The name attribute is mandatory.
>+Available limit names are:</para>
>+<literallayout remap='.nf'>
>+      "max_incoming_bytes"         : total size in bytes of messages
>+                                     incoming from a single connection
>+      "max_incoming_unix_fds"      : total number of unix fds of messages
>+                                     incoming from a single connection
>+      "max_outgoing_bytes"         : total size in bytes of messages
>+                                     queued up for a single connection
>+      "max_outgoing_unix_fds"      : total number of unix fds of messages
>+                                     queued up for a single connection
>+      "max_message_size"           : max size of a single message in
>+                                     bytes
>+      "max_message_unix_fds"       : max unix fds of a single message
>+      "service_start_timeout"      : milliseconds (thousandths) until
>+                                     a started service has to connect
>+      "auth_timeout"               : milliseconds (thousandths) a
>+                                     connection is given to
>+                                     authenticate
>+      "max_completed_connections"  : max number of authenticated connections
>+      "max_incomplete_connections" : max number of unauthenticated
>+                                     connections
>+      "max_connections_per_user"   : max number of completed connections from
>+                                     the same user
>+      "max_pending_service_starts" : max number of service launches in
>+                                     progress at the same time
>+      "max_names_per_connection"   : max number of names a single
>+                                     connection can own
>+      "max_match_rules_per_connection": max number of match rules for a single
>+                                        connection
>+      "max_replies_per_connection" : max number of pending method
>+                                     replies per connection
>+                                     (number of calls-in-progress)
>+      "reply_timeout"              : milliseconds (thousandths)
>+                                     until a method call times out
>+</literallayout> 
>+
>+
>+<para>The max incoming/outgoing queue sizes allow a new message to be queued
>+if one byte remains below the max. So you can in fact exceed the max
>+by max_message_size.</para>
>+
>+
>+<para>max_completed_connections divided by max_connections_per_user is the
>+number of users that can work together to denial-of-service all other users by using
>+up all connections on the systemwide bus.</para>
>+
>+
>+<para>Limits are normally only of interest on the systemwide bus, not the user session
>+buses.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;policy&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>The &lt;policy&gt; element defines a security policy to be applied to a particular
>+set of connections to the bus. A policy is made up of
>+&lt;allow&gt; and &lt;deny&gt; elements. Policies are normally used with the systemwide bus;
>+they are analogous to a firewall in that they allow expected traffic
>+and prevent unexpected traffic.</para>
>+
>+
>+<para>Currently, the system bus has a default-deny policy for sending method calls
>+and owning bus names.  Everything else, in particular reply messages, receive
>+checks, and signals has a default allow policy.</para>
>+
>+
>+<para>In general, it is best to keep system services as small, targeted programs which
>+run in their own process and provide a single bus name.  Then, all that is needed
>+is an &lt;allow&gt; rule for the "own" permission to let the process claim the bus
>+name, and a "send_destination" rule to allow traffic from some or all uids to
>+your service.</para>
>+
>+
>+<para>The &lt;policy&gt; element has one of four attributes:</para>
>+<literallayout remap='.nf'>
>+  context="(default|mandatory)"
>+  at_console="(true|false)"
>+  user="username or userid"
>+  group="group name or gid"
>+</literallayout> 
>+
>+
>+<para>Policies are applied to a connection as follows:</para>
>+<literallayout remap='.nf'>
>+   - all context="default" policies are applied
>+   - all group="connection's user's group" policies are applied
>+     in undefined order
>+   - all user="connection's auth user" policies are applied
>+     in undefined order
>+   - all at_console="true" policies are applied
>+   - all at_console="false" policies are applied
>+   - all context="mandatory" policies are applied
>+</literallayout> 
>+
>+
>+<para>Policies applied later will override those applied earlier,
>+when the policies overlap. Multiple policies with the same
>+user/group/context are applied in the order they appear
>+in the config file.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;deny&gt;</emphasis></term>
>+  <listitem>
>+<para><emphasis remap='I'>&lt;allow&gt;</emphasis></para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>A &lt;deny&gt; element appears below a &lt;policy&gt; element and prohibits some
>+action. The &lt;allow&gt; element makes an exception to previous &lt;deny&gt;
>+statements, and works just like &lt;deny&gt; but with the inverse meaning.</para>
>+
>+
>+<para>The possible attributes of these elements are:</para>
>+<literallayout remap='.nf'>
>+   send_interface="interface_name"
>+   send_member="method_or_signal_name"
>+   send_error="error_name"
>+   send_destination="name"
>+   send_type="method_call" | "method_return" | "signal" | "error"
>+   send_path="/path/name"
>+
>+   receive_interface="interface_name"
>+   receive_member="method_or_signal_name"
>+   receive_error="error_name"
>+   receive_sender="name"
>+   receive_type="method_call" | "method_return" | "signal" | "error"
>+   receive_path="/path/name"
>+
>+   send_requested_reply="true" | "false"
>+   receive_requested_reply="true" | "false"
>+
>+   eavesdrop="true" | "false"
>+
>+   own="name"
>+   own_prefix="name"
>+   user="username"
>+   group="groupname"
>+</literallayout> 
>+
>+
>+<para>Examples:</para>
>+<literallayout remap='.nf'>
>+   &lt;deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/&gt;
>+   &lt;deny send_destination="org.freedesktop.System"/&gt;
>+   &lt;deny receive_sender="org.freedesktop.System"/&gt;
>+   &lt;deny user="john"/&gt;
>+   &lt;deny group="enemies"/&gt;
>+</literallayout> 
>+
>+
>+<para>The &lt;deny&gt; element's attributes determine whether the deny "matches" a
>+particular action. If it matches, the action is denied (unless later
>+rules in the config file allow it).</para>
>+
>+<para>send_destination and receive_sender rules mean that messages may not be
>+sent to or received from the *owner* of the given name, not that
>+they may not be sent *to that name*. That is, if a connection
>+owns services A, B, C, and sending to A is denied, sending to B or C
>+will not work either.</para>
>+
>+<para>The other send_* and receive_* attributes are purely textual/by-value
>+matches against the given field in the message header.</para>
>+
>+<para>"Eavesdropping" occurs when an application receives a message that
>+was explicitly addressed to a name the application does not own, or
>+is a reply to such a message. Eavesdropping thus only applies to
>+messages that are addressed to services and replies to such messages
>+(i.e. it does not apply to signals).</para>
>+
>+<para>For &lt;allow&gt;, eavesdrop="true" indicates that the rule matches even
>+when eavesdropping. eavesdrop="false" is the default and means that
>+the rule only allows messages to go to their specified recipient.
>+For &lt;deny&gt;, eavesdrop="true" indicates that the rule matches
>+only when eavesdropping. eavesdrop="false" is the default for &lt;deny&gt;
>+also, but here it means that the rule applies always, even when
>+not eavesdropping. The eavesdrop attribute can only be combined with
>+send and receive rules (with send_* and receive_* attributes).</para>
>+
>+<para>The [send|receive]_requested_reply attribute works similarly to the eavesdrop
>+attribute. It controls whether the &lt;deny&gt; or &lt;allow&gt; matches a reply
>+that is expected (corresponds to a previous method call message).
>+This attribute only makes sense for reply messages (errors and method
>+returns), and is ignored for other message types.</para>
>+
>+
>+<para>For &lt;allow&gt;, [send|receive]_requested_reply="true" is the default and indicates that
>+only requested replies are allowed by the
>+rule. [send|receive]_requested_reply="false" means that the rule allows any reply
>+even if unexpected.</para>
>+
>+
>+<para>For &lt;deny&gt;, [send|receive]_requested_reply="false" is the default but indicates that
>+the rule matches only when the reply was not
>+requested. [send|receive]_requested_reply="true" indicates that the rule applies
>+always, regardless of pending reply state.</para>
>+
>+
>+<para>user and group denials mean that the given user or group may
>+not connect to the message bus.</para>
>+
>+
>+<para>For "name", "username", "groupname", etc.
>+the character "*" can be substituted, meaning "any." Complex globs
>+like "foo.bar.*" aren't allowed for now because they'd be work to
>+implement and maybe encourage sloppy security anyway.</para>
>+
>+
>+<para>&lt;allow own_prefix="a.b"/&gt; allows you to own the name "a.b" or any
>+name whose first dot-separated elements are "a.b": in particular,
>+you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c".
>+This is useful when services like Telepathy and ReserveDevice
>+define a meaning for subtrees of well-known names, such as
>+org.freedesktop.Telepathy.ConnectionManager.(anything)
>+and org.freedesktop.ReserveDevice1.(anything).</para>
>+
>+
>+<para>It does not make sense to deny a user or group inside a &lt;policy&gt;
>+for a user or group; user/group denials can only be inside
>+context="default" or context="mandatory" policies.</para>
>+
>+
>+<para>A single &lt;deny&gt; rule may specify combinations of attributes such as
>+send_destination and send_interface and send_type. In this case, the
>+denial applies only if both attributes match the message being denied.
>+e.g. &lt;deny send_interface="foo.bar" send_destination="foo.blah"/&gt; would
>+deny messages with the given interface AND the given bus name.
>+To get an OR effect you specify multiple &lt;deny&gt; rules.</para>
>+
>+
>+<para>You can't include both send_ and receive_ attributes on the same
>+rule, since "whether the message can be sent" and "whether it can be
>+received" are evaluated separately.</para>
>+
>+
>+<para>Be careful with send_interface/receive_interface, because the
>+interface field in messages is optional.  In particular, do NOT
>+specify &lt;deny send_interface="org.foo.Bar"/&gt;!  This will cause
>+no-interface messages to be blocked for all services, which is
>+almost certainly not what you intended.  Always use rules of
>+the form: &lt;deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/&gt;</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;selinux&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>The &lt;selinux&gt; element contains settings related to Security Enhanced Linux.
>+More details below.</para>
>+
>+<itemizedlist remap='TP'>
>+
>+  <listitem><para><emphasis remap='I'>&lt;associate&gt;</emphasis></para></listitem>
>+
>+
>+</itemizedlist>
>+
>+<para>An &lt;associate&gt; element appears below an &lt;selinux&gt; element and
>+creates a mapping. Right now only one kind of association is possible:</para>
>+<literallayout remap='.nf'>
>+   &lt;associate own="org.freedesktop.Foobar" context="foo_t"/&gt;
>+</literallayout> 
>+
>+
>+<para>This means that if a connection asks to own the name
>+"org.freedesktop.Foobar" then the source context will be the context
>+of the connection and the target context will be "foo_t" - see the
>+short discussion of SELinux below.</para>
>+
>+
>+<para>Note, the context here is the target context when requesting a name,
>+NOT the context of the connection owning the name.</para>
>+
>+
>+<para>There's currently no way to set a default for owning any name, if
>+we add this syntax it will look like:</para>
>+<literallayout remap='.nf'>
>+   &lt;associate own="*" context="foo_t"/&gt;
>+</literallayout> 
>+<para>If you find a reason this is useful, let the developers know.
>+Right now the default will be the security context of the bus itself.</para>
>+
>+
>+<para>If two &lt;associate&gt; elements specify the same name, the element
>+appearing later in the configuration file will be used.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='selinux'><title>SELinux</title>
>+<para>See <ulink url='http://www.nsa.gov/selinux/'>http://www.nsa.gov/selinux/</ulink> for full details on SELinux. Some useful excerpts:</para>
>+
>+
>+<para>Every subject (process) and object (e.g. file, socket, IPC object,
>+etc) in the system is assigned a collection of security attributes,
>+known as a security context. A security context contains all of the
>+security attributes associated with a particular subject or object
>+that are relevant to the security policy.</para>
>+
>+
>+<para>In order to better encapsulate security contexts and to provide
>+greater efficiency, the policy enforcement code of SELinux typically
>+handles security identifiers (SIDs) rather than security contexts. A
>+SID is an integer that is mapped by the security server to a security
>+context at runtime.</para>
>+
>+
>+<para>When a security decision is required, the policy enforcement code
>+passes a pair of SIDs (typically the SID of a subject and the SID of
>+an object, but sometimes a pair of subject SIDs or a pair of object
>+SIDs), and an object security class to the security server. The object
>+security class indicates the kind of object, e.g. a process, a regular
>+file, a directory, a TCP socket, etc.</para>
>+
>+
>+<para>Access decisions specify whether or not a permission is granted for a
>+given pair of SIDs and class. Each object class has a set of
>+associated permissions defined to control operations on objects with
>+that class.</para>
>+
>+
>+<para>D-Bus performs SELinux security checks in two places.</para>
>+
>+
>+<para>First, any time a message is routed from one connection to another
>+connection, the bus daemon will check permissions with the security context of
>+the first connection as source, security context of the second connection
>+as target, object class "dbus" and requested permission "send_msg".</para>
>+
>+
>+<para>If a security context is not available for a connection
>+(impossible when using UNIX domain sockets), then the target
>+context used is the context of the bus daemon itself.
>+There is currently no way to change this default, because we're
>+assuming that only UNIX domain sockets will be used to
>+connect to the systemwide bus. If this changes, we'll
>+probably add a way to set the default connection context.</para>
>+
>+
>+<para>Second, any time a connection asks to own a name,
>+the bus daemon will check permissions with the security
>+context of the connection as source, the security context specified
>+for the name in the config file as target, object
>+class "dbus" and requested permission "acquire_svc".</para>
>+
>+
>+<para>The security context for a bus name is specified with the
>+&lt;associate&gt; element described earlier in this document.
>+If a name has no security context associated in the
>+configuration file, the security context of the bus daemon
>+itself will be used.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='debugging'><title>DEBUGGING</title>
>+<para>If you're trying to figure out where your messages are going or why
>+you aren't getting messages, there are several things you can try.</para>
>+
>+<para>Remember that the system bus is heavily locked down and if you
>+haven't installed a security policy file to allow your message
>+through, it won't work. For the session bus, this is not a concern.</para>
>+
>+<para>The simplest way to figure out what's happening on the bus is to run
>+the <emphasis remap='I'>dbus-monitor</emphasis> program, which comes with the D-Bus
>+package. You can also send test messages with <emphasis remap='I'>dbus-send</emphasis>. These
>+programs have their own man pages.</para>
>+
>+<para>If you want to know what the daemon itself is doing, you might consider
>+running a separate copy of the daemon to test against. This will allow you
>+to put the daemon under a debugger, or run it with verbose output, without
>+messing up your real session and system daemons.</para>
>+
>+<para>To run a separate test copy of the daemon, for example you might open a terminal
>+and type:</para>
>+<literallayout remap='.nf'>
>+  DBUS_VERBOSE=1 dbus-daemon --session --print-address
>+</literallayout> 
>+
>+<para>The test daemon address will be printed when the daemon starts. You will need
>+to copy-and-paste this address and use it as the value of the
>+DBUS_SESSION_BUS_ADDRESS environment variable when you launch the applications
>+you want to test. This will cause those applications to connect to your
>+test bus instead of the DBUS_SESSION_BUS_ADDRESS of your real session bus.</para>
>+
>+<para>DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus
>+was compiled with verbose mode enabled. This is not recommended in
>+production builds due to performance impact. You may need to rebuild
>+D-Bus if your copy was not built with debugging in mind. (DBUS_VERBOSE
>+also affects the D-Bus library and thus applications using D-Bus; it may
>+be useful to see verbose output on both the client side and from the daemon.)</para>
>+
>+<para>If you want to get fancy, you can create a custom bus
>+configuration for your test bus (see the session.conf and system.conf
>+files that define the two default configurations for example). This
>+would allow you to specify a different directory for .service files,
>+for example.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>diff --git a/doc/dbus-daemon.xml.in b/doc/dbus-daemon.xml.in
>new file mode 100644
>index 0000000..f331699
>--- /dev/null
>+++ b/doc/dbus-daemon.xml.in
>@@ -0,0 +1,752 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
>+
>+<refentry id='dbus-daemon'>
>+
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-daemon</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv id='name'>
>+<refname>dbus-daemon</refname>
>+<refpurpose>Message bus daemon</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-daemon</command></cmdsynopsis>
>+<cmdsynopsis>
>+  <command>dbus-daemon</command>    <arg choice='opt'>--version </arg>
>+    <arg choice='opt'>--session </arg>
>+    <arg choice='opt'>--system </arg>
>+    <arg choice='opt'>--config-file=<replaceable>FILE</replaceable></arg>
>+    <arg choice='opt'><arg choice='plain'>--print-address </arg><arg choice='opt'><replaceable>=DESCRIPTOR</replaceable></arg></arg>
>+    <arg choice='opt'><arg choice='plain'>--print-pid </arg><arg choice='opt'><replaceable>=DESCRIPTOR</replaceable></arg></arg>
>+    <arg choice='opt'>--fork </arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para><command>dbus-daemon</command> is the D-Bus message bus daemon. See
>+<ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about
>+the big picture. D-Bus is first a library that provides one-to-one
>+communication between any two applications; <command>dbus-daemon</command> is an
>+application that uses this library to implement a message bus
>+daemon. Multiple programs connect to the message bus daemon and can
>+exchange messages with one another.</para>
>+
>+
>+<para>There are two standard message bus instances: the systemwide message bus 
>+(installed on many systems as the "messagebus" init service) and the 
>+per-user-login-session message bus (started each time a user logs in).
>+<command>dbus-daemon</command> is used for both of these instances, but with 
>+a different configuration file.</para>
>+
>+
>+<para>The --session option is equivalent to
>+"--config-file=/etc/dbus-1/session.conf" and the --system
>+option is equivalent to
>+"--config-file=/etc/dbus-1/system.conf". By creating 
>+additional configuration files and using the --config-file option,
>+additional special-purpose message bus daemons could be created.</para>
>+
>+
>+<para>The systemwide daemon is normally launched by an init script, 
>+standardly called simply "messagebus".</para> 
>+
>+
>+<para>The systemwide daemon is largely used for broadcasting system events, 
>+such as changes to the printer queue, or adding/removing devices.</para>
>+
>+
>+<para>The per-session daemon is used for various interprocess communication 
>+among desktop applications (however, it is not tied to X or the GUI 
>+in any way).</para>
>+
>+
>+<para>SIGHUP will cause the D-Bus daemon to PARTIALLY reload its
>+configuration file and to flush its user/group information caches. Some
>+configuration changes would require kicking all apps off the bus; so they will
>+only take effect if you restart the daemon. Policy changes should take effect
>+with SIGHUP.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<para>The following options are supported:</para>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--config-file=FILE</option></term>
>+  <listitem>
>+<para>Use the given configuration file.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--fork</option></term>
>+  <listitem>
>+<para>Force the message bus to fork and become a daemon, even if 
>+the configuration file does not specify that it should.
>+In most contexts the configuration file already gets this
>+right, though.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--print-address[=DESCRIPTOR]</option></term>
>+  <listitem>
>+<para>Print the address of the message bus to standard output, or 
>+to the given file descriptor. This is used by programs that 
>+launch the message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--print-pid[=DESCRIPTOR]</option></term>
>+  <listitem>
>+<para>Print the process ID of the message bus to standard output, or 
>+to the given file descriptor. This is used by programs that 
>+launch the message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--session</option></term>
>+  <listitem>
>+<para>Use the standard configuration file for the per-login-session message
>+bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--system</option></term>
>+  <listitem>
>+<para>Use the standard configuration file for the systemwide message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--version</option></term>
>+  <listitem>
>+<para>Print the version of the daemon.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='configuration_file'><title>CONFIGURATION FILE</title>
>+<para>A message bus daemon has a configuration file that specializes it
>+for a particular application. For example, one configuration 
>+file might set up the message bus to be a systemwide message bus, 
>+while another might set it up to be a per-user-login-session bus.</para>
>+
>+
>+<para>The configuration file also establishes resource limits, security
>+parameters, and so forth.</para>
>+
>+
>+<para>The configuration file is not part of any interoperability
>+specification and its backward compatibility is not guaranteed; this
>+document is documentation, not specification.</para>
>+
>+
>+<para>The standard systemwide and per-session message bus setups are
>+configured in the files "/etc/dbus-1/system.conf" and
>+"/etc/dbus-1/session.conf".  These files normally
>+&lt;include&gt; a system-local.conf or session-local.conf; you can put local
>+overrides in those files to avoid modifying the primary configuration
>+files.</para>
>+
>+
>+<para>The configuration file is an XML document. It must have the following
>+doctype declaration:</para>
>+<literallayout remap='.nf'>
>+
>+   &lt;!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
>+    "<ulink url='http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd'>http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd</ulink>"&gt;
>+
>+</literallayout> 
>+
>+
>+<para>The following elements may be present in the configuration file.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;busconfig&gt;</emphasis></term>
>+  <listitem>
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>Root element.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;type&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>The well-known type of the message bus. Currently known values are
>+"system" and "session"; if other values are set, they should be
>+either added to the D-Bus specification, or namespaced.  The last
>+&lt;type&gt; element "wins" (previous values are ignored).</para>
>+
>+
>+<para>Example: &lt;type&gt;session&lt;/type&gt;</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;include&gt;</emphasis></term>
>+  <listitem>
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>Include a file &lt;include&gt;filename.conf&lt;/include&gt; at this point.  If the
>+filename is relative, it is located relative to the configuration file
>+doing the including.</para>
>+
>+
>+<para>&lt;include&gt; has an optional attribute "ignore_missing=(yes|no)"
>+which defaults to "no" if not provided. This attribute 
>+controls whether it's a fatal error for the included file 
>+to be absent.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;includedir&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>Include all files in &lt;includedir&gt;foo.d&lt;/includedir&gt; at this
>+point. Files in the directory are included in undefined order.
>+Only files ending in ".conf" are included.</para>
>+
>+
>+<para>This is intended to allow extension of the system bus by particular
>+packages. For example, if CUPS wants to be able to send out
>+notification of printer queue changes, it could install a file to
>+/etc/dbus-1/system.d that allowed all apps to receive
>+this message and allowed the printer daemon user to send it.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;user&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>The user account the daemon should run as, as either a username or a
>+UID. If the daemon cannot change to this UID on startup, it will exit.
>+If this element is not present, the daemon will not change or care
>+about its UID.</para>
>+
>+
>+<para>The last &lt;user&gt; entry in the file "wins", the others are ignored.</para>
>+
>+
>+<para>The user is changed after the bus has completed initialization.  So
>+sockets etc. will be created before changing user, but no data will be
>+read from clients before changing user. This means that sockets 
>+and PID files can be created in a location that requires root 
>+privileges for writing.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;fork&gt;</emphasis></term>
>+  <listitem>
>+<para></para>    
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>If present, the bus daemon becomes a real daemon (forks 
>+into the background, etc.). This is generally used 
>+rather than the --fork command line option.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;listen&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>Add an address that the bus should listen on. The 
>+address is in the standard D-Bus format that contains 
>+a transport name plus possible parameters/options.</para>
>+
>+
>+<para>Example: &lt;listen&gt;unix:path=/tmp/foo&lt;/listen&gt;</para>
>+
>+
>+<para>If there are multiple &lt;listen&gt; elements, then the bus listens 
>+on multiple addresses. The bus will pass its address to 
>+started services or other interested parties with 
>+the last address given in &lt;listen&gt; first. That is, 
>+apps will try to connect to the last &lt;listen&gt; address first.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;auth&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>Lists permitted authorization mechanisms. If this element doesn't
>+exist, then all known mechanisms are allowed.  If there are multiple
>+&lt;auth&gt; elements, all the listed mechanisms are allowed.  The order in
>+which mechanisms are listed is not meaningful.</para>
>+    
>+
>+<para>Example: &lt;auth&gt;EXTERNAL&lt;/auth&gt;</para>
>+
>+
>+<para>Example: &lt;auth&gt;DBUS_COOKIE_SHA1&lt;/auth&gt;</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;servicedir&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>Adds a directory to scan for .service files. Directories are
>+scanned starting with the last to appear in the config file 
>+(the first .service file found that provides a particular 
>+service will be used).</para>
>+
>+
>+<para>Service files tell the bus how to automatically start a program.
>+They are primarily used with the per-user-session bus, 
>+not the systemwide bus.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;standard_session_servicedirs/&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>&lt;standard_session_servicedirs/&gt; is equivalent to specifying a series
>+of &lt;servicedir/&gt; elements for each of the data directories in the "XDG
>+Base Directory Specification" with the subdirectory "dbus-1/services",
>+so for example "/usr/share/dbus-1/services" would be among the
>+directories searched.</para>
>+
>+
>+<para>The "XDG Base Directory Specification" can be found at
>+<ulink url='http://freedesktop.org/wiki/Standards/basedir-spec'>http://freedesktop.org/wiki/Standards/basedir-spec</ulink> if it hasn't moved,
>+otherwise try your favorite search engine.</para>
>+
>+
>+<para>The &lt;standard_session_servicedirs/&gt; option is only relevant to the
>+per-user-session bus daemon defined in
>+/etc/dbus-1/session.conf. Putting it in any other
>+configuration file would probably be nonsense.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;limit&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>&lt;limit&gt; establishes a resource limit. For example:</para>
>+<literallayout remap='.nf'>
>+  &lt;limit name="max_message_size"&gt;64&lt;/limit&gt;
>+  &lt;limit name="max_completed_connections"&gt;512&lt;/limit&gt;
>+</literallayout> 
>+
>+
>+<para>The name attribute is mandatory.
>+Available limit names are:</para>
>+<literallayout remap='.nf'>
>+      "max_incoming_bytes"         : total size in bytes of messages
>+                                     incoming from a single connection
>+      "max_outgoing_bytes"         : total size in bytes of messages
>+                                     queued up for a single connection
>+      "max_message_size"           : max size of a single message in
>+                                     bytes
>+      "service_start_timeout"      : milliseconds (thousandths) until 
>+                                     a started service has to connect
>+      "auth_timeout"               : milliseconds (thousandths) a
>+                                     connection is given to
>+                                     authenticate
>+      "max_completed_connections"  : max number of authenticated connections  
>+      "max_incomplete_connections" : max number of unauthenticated
>+                                     connections
>+      "max_connections_per_user"   : max number of completed connections from
>+                                     the same user
>+      "max_pending_service_starts" : max number of service launches in
>+                                     progress at the same time
>+      "max_names_per_connection"   : max number of names a single 
>+                                     connection can own
>+      "max_match_rules_per_connection": max number of match rules for a single 
>+                                        connection
>+      "max_replies_per_connection" : max number of pending method 
>+                                     replies per connection
>+                                     (number of calls-in-progress)
>+      "reply_timeout"              : milliseconds (thousandths) 
>+                                     until a method call times out   
>+</literallayout> 
>+
>+
>+<para>The max incoming/outgoing queue sizes allow a new message to be queued
>+if one byte remains below the max. So you can in fact exceed the max
>+by max_message_size.</para>
>+
>+
>+<para>max_completed_connections divided by max_connections_per_user is the
>+number of users that can work together to denial-of-service all other users by using
>+up all connections on the systemwide bus.</para>
>+
>+
>+<para>Limits are normally only of interest on the systemwide bus, not the user session 
>+buses.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;policy&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>The &lt;policy&gt; element defines a security policy to be applied to a particular
>+set of connections to the bus. A policy is made up of
>+&lt;allow&gt; and &lt;deny&gt; elements. Policies are normally used with the systemwide bus;
>+they are analogous to a firewall in that they allow expected traffic 
>+and prevent unexpected traffic.</para>
>+
>+
>+<para>The &lt;policy&gt; element has one of three attributes:</para>
>+<literallayout remap='.nf'>
>+  context="(default|mandatory)"
>+  user="username or userid"
>+  group="group name or gid"
>+</literallayout> 
>+
>+
>+<para> 
>+Policies are applied to a connection as follows:</para>
>+<literallayout remap='.nf'>
>+   - all context="default" policies are applied
>+   - all group="connection's user's group" policies are applied
>+     in undefined order
>+   - all user="connection's auth user" policies are applied
>+     in undefined order
>+   - all context="mandatory" policies are applied
>+</literallayout> 
>+
>+
>+<para>Policies applied later will override those applied earlier, 
>+when the policies overlap. Multiple policies with the same 
>+user/group/context are applied in the order they appear 
>+in the config file.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;deny&gt;</emphasis></term>
>+  <listitem>
>+<para><emphasis remap='I'>&lt;allow&gt;</emphasis></para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>A &lt;deny&gt; element appears below a &lt;policy&gt; element and prohibits some
>+action. The &lt;allow&gt; element makes an exception to previous &lt;deny&gt;
>+statements, and works just like &lt;deny&gt; but with the inverse meaning.</para>
>+
>+
>+<para>The possible attributes of these elements are:</para>
>+<literallayout remap='.nf'>
>+   send_interface="interface_name"
>+   send_member="method_or_signal_name" 
>+   send_error="error_name" 
>+   send_destination="name" 
>+   send_type="method_call" | "method_return" | "signal" | "error" 
>+   send_path="/path/name"
>+
>+   receive_interface="interface_name"
>+   receive_member="method_or_signal_name" 
>+   receive_error="error_name" 
>+   receive_sender="name" 
>+   receive_type="method_call" | "method_return" | "signal" | "error"
>+   receive_path="/path/name"
>+
>+   send_requested_reply="true" | "false"
>+   receive_requested_reply="true" | "false"
>+
>+   eavesdrop="true" | "false"
>+
>+   own="name"
>+   own_prefix="name"
>+   user="username"
>+   group="groupname"
>+</literallayout> 
>+
>+
>+<para>Examples:</para>
>+<literallayout remap='.nf'>
>+   &lt;deny send_interface="org.freedesktop.System" send_member="Reboot"/&gt; 
>+   &lt;deny receive_interface="org.freedesktop.System" receive_member="Reboot"/&gt;
>+   &lt;deny own="org.freedesktop.System"/&gt;
>+   &lt;deny send_destination="org.freedesktop.System"/&gt;
>+   &lt;deny receive_sender="org.freedesktop.System"/&gt;
>+   &lt;deny user="john"/&gt;
>+   &lt;deny group="enemies"/&gt;
>+</literallayout> 
>+
>+
>+<para>The &lt;deny&gt; element's attributes determine whether the deny "matches" a
>+particular action. If it matches, the action is denied (unless later
>+rules in the config file allow it).</para>
>+
>+
>+<para>send_destination and receive_sender rules mean that messages may not be
>+sent to or received from the *owner* of the given name, not that
>+they may not be sent *to that name*. That is, if a connection
>+owns services A, B, C, and sending to A is denied, sending to B or C
>+will not work either.</para>
>+
>+
>+<para>The other send_* and receive_* attributes are purely textual/by-value
>+matches against the given field in the message header.</para>
>+
>+
>+<para>"Eavesdropping" occurs when an application receives a message that
>+was explicitly addressed to a name the application does not own.
>+Eavesdropping thus only applies to messages that are addressed to
>+services (i.e. it does not apply to signals).</para>
>+
>+
>+<para>For &lt;allow&gt;, eavesdrop="true" indicates that the rule matches even 
>+when eavesdropping. eavesdrop="false" is the default and means that 
>+the rule only allows messages to go to their specified recipient.
>+For &lt;deny&gt;, eavesdrop="true" indicates that the rule matches 
>+only when eavesdropping. eavesdrop="false" is the default for &lt;deny&gt;
>+also, but here it means that the rule applies always, even when 
>+not eavesdropping. The eavesdrop attribute can only be combined with
>+receive rules (with receive_* attributes).</para>
>+
>+
>+
>+<para>The [send|receive]_requested_reply attribute works similarly to the eavesdrop
>+attribute. It controls whether the &lt;deny&gt; or &lt;allow&gt; matches a reply
>+that is expected (corresponds to a previous method call message).
>+This attribute only makes sense for reply messages (errors and method
>+returns), and is ignored for other message types.</para>
>+
>+
>+<para>For &lt;allow&gt;, [send|receive]_requested_reply="true" is the default and indicates that
>+only requested replies are allowed by the
>+rule. [send|receive]_requested_reply="false" means that the rule allows any reply
>+even if unexpected.</para>
>+
>+
>+<para>For &lt;deny&gt;, [send|receive]_requested_reply="false" is the default but indicates that
>+the rule matches only when the reply was not
>+requested. [send|receive]_requested_reply="true" indicates that the rule applies
>+always, regardless of pending reply state.</para>
>+
>+
>+<para>user and group denials mean that the given user or group may 
>+not connect to the message bus.</para>
>+
>+
>+<para>For "name", "username", "groupname", etc.
>+the character "*" can be substituted, meaning "any." Complex globs
>+like "foo.bar.*" aren't allowed for now because they'd be work to
>+implement and maybe encourage sloppy security anyway.</para>
>+
>+<para>&lt;allow own_prefix="a.b"/&gt; allows you to own the name "a.b" or any
>+name whose first dot-separated elements are "a.b": in particular,
>+you can own "a.b.c" or "a.b.c.d", but not "a.bc" or "a.c".
>+This is useful when services like Telepathy and ReserveDevice
>+define a meaning for subtrees of well-known names, such as
>+org.freedesktop.Telepathy.ConnectionManager.(anything)
>+and org.freedesktop.ReserveDevice1.(anything).</para>
>+
>+<para>It does not make sense to deny a user or group inside a &lt;policy&gt;
>+for a user or group; user/group denials can only be inside
>+context="default" or context="mandatory" policies.</para>
>+
>+
>+<para>A single &lt;deny&gt; rule may specify combinations of attributes such as
>+send_destination and send_interface and send_type. In this case, the
>+denial applies only if both attributes match the message being denied.
>+e.g. &lt;deny send_interface="foo.bar" send_destination="foo.blah"/&gt; would
>+deny messages with the given interface AND the given bus name.
>+To get an OR effect you specify multiple &lt;deny&gt; rules.</para>
>+
>+
>+<para>You can't include both send_ and receive_ attributes on the same
>+rule, since "whether the message can be sent" and "whether it can be
>+received" are evaluated separately.</para>
>+
>+
>+<para>Be careful with send_interface/receive_interface, because the 
>+interface field in messages is optional.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;selinux&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>The &lt;selinux&gt; element contains settings related to Security Enhanced Linux.
>+More details below.</para>
>+
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><emphasis remap='I'>&lt;associate&gt;</emphasis></term>
>+  <listitem>
>+
>+<para></para> 
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+
>+<para>An &lt;associate&gt; element appears below an &lt;selinux&gt; element and
>+creates a mapping. Right now only one kind of association is possible:</para>
>+<literallayout remap='.nf'>
>+   &lt;associate own="org.freedesktop.Foobar" context="foo_t"/&gt; 
>+</literallayout> 
>+
>+
>+<para>This means that if a connection asks to own the name
>+"org.freedesktop.Foobar" then the source context will be the context
>+of the connection and the target context will be "foo_t" - see the 
>+short discussion of SELinux below.</para>
>+
>+
>+<para>Note, the context here is the target context when requesting a name,
>+NOT the context of the connection owning the name.</para>
>+
>+
>+<para>There's currently no way to set a default for owning any name, if
>+we add this syntax it will look like:</para>
>+<literallayout remap='.nf'>
>+   &lt;associate own="*" context="foo_t"/&gt; 
>+</literallayout> 
>+<para>If you find a reason this is useful, let the developers know.
>+Right now the default will be the security context of the bus itself.</para>
>+
>+
>+<para>If two &lt;associate&gt; elements specify the same name, the element
>+appearing later in the configuration file will be used.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='selinux'><title>SELinux</title>
>+<para>See <ulink url='http://www.nsa.gov/selinux/'>http://www.nsa.gov/selinux/</ulink> for full details on SELinux. Some useful excerpts:</para>
>+
>+
>+<para>Every subject (process) and object (e.g. file, socket, IPC object,
>+etc) in the system is assigned a collection of security attributes,
>+known as a security context. A security context contains all of the
>+security attributes associated with a particular subject or object
>+that are relevant to the security policy.</para>
>+
>+
>+<para>In order to better encapsulate security contexts and to provide
>+greater efficiency, the policy enforcement code of SELinux typically
>+handles security identifiers (SIDs) rather than security contexts. A
>+SID is an integer that is mapped by the security server to a security
>+context at runtime.</para>
>+
>+
>+<para>When a security decision is required, the policy enforcement code
>+passes a pair of SIDs (typically the SID of a subject and the SID of
>+an object, but sometimes a pair of subject SIDs or a pair of object
>+SIDs), and an object security class to the security server. The object
>+security class indicates the kind of object, e.g. a process, a regular
>+file, a directory, a TCP socket, etc.</para>
>+
>+
>+<para>Access decisions specify whether or not a permission is granted for a
>+given pair of SIDs and class. Each object class has a set of
>+associated permissions defined to control operations on objects with
>+that class.</para>
>+
>+
>+<para>D-Bus performs SELinux security checks in two places.</para>
>+
>+
>+<para>First, any time a message is routed from one connection to another
>+connection, the bus daemon will check permissions with the security context of
>+the first connection as source, security context of the second connection
>+as target, object class "dbus" and requested permission "send_msg".</para>
>+
>+
>+<para>If a security context is not available for a connection 
>+(impossible when using UNIX domain sockets), then the target 
>+context used is the context of the bus daemon itself.
>+There is currently no way to change this default, because we're 
>+assuming that only UNIX domain sockets will be used to 
>+connect to the systemwide bus. If this changes, we'll 
>+probably add a way to set the default connection context.</para>
>+
>+
>+<para>Second, any time a connection asks to own a name, 
>+the bus daemon will check permissions with the security 
>+context of the connection as source, the security context specified
>+for the name in the config file as target, object 
>+class "dbus" and requested permission "acquire_svc".</para>
>+
>+
>+<para>The security context for a bus name is specified with the 
>+&lt;associate&gt; element described earlier in this document.
>+If a name has no security context associated in the 
>+configuration file, the security context of the bus daemon 
>+itself will be used.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>diff --git a/doc/dbus-launch.1.xml b/doc/dbus-launch.1.xml
>new file mode 100644
>index 0000000..ab4d5ed
>--- /dev/null
>+++ b/doc/dbus-launch.1.xml
>@@ -0,0 +1,270 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
>+
>+<refentry id='dbuslaunch1'>
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-launch</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv>
>+<refname>dbus-launch</refname>
>+<refpurpose>Utility to start a message bus from a shell script</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-launch</command>    <arg choice='opt'>--version </arg>
>+    <arg choice='opt'>--sh-syntax </arg>
>+    <arg choice='opt'>--csh-syntax </arg>
>+    <arg choice='opt'>--auto-syntax </arg>
>+    <arg choice='opt'>--exit-with-session </arg>
>+    <arg choice='opt'>--autolaunch=<replaceable>MACHINEID</replaceable></arg>
>+    <arg choice='opt'>--config-file=<replaceable>FILENAME</replaceable></arg>
>+    <arg choice='opt'><replaceable>PROGRAM</replaceable></arg>
>+    <arg choice='opt' rep='repeat'><replaceable>ARGS</replaceable></arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para>The <command>dbus-launch</command> command is used to start a session bus 
>+instance of <emphasis remap='I'>dbus-daemon</emphasis> from a shell script.
>+It would normally be called from a user's login
>+scripts. Unlike the daemon itself, <command>dbus-launch</command> exits, so
>+backticks or the $() construct can be used to read information from
>+<command>dbus-launch</command>.</para>
>+
>+<para>With no arguments, <command>dbus-launch</command> will launch a session bus
>+instance and print the address and PID of that instance to standard
>+output.</para>
>+
>+<para>You may specify a program to be run; in this case, <command>dbus-launch</command>
>+will launch a session bus instance, set the appropriate environment
>+variables so the specified program can find the bus, and then execute the
>+specified program, with the specified arguments.  See below for
>+examples.</para>
>+
>+<para>If you launch a program, <command>dbus-launch</command> will not print the
>+information about the new bus to standard output.</para>
>+
>+<para>When <command>dbus-launch</command> prints bus information to standard output, by
>+default it is in a simple key-value pairs format. However, you may 
>+request several alternate syntaxes using the --sh-syntax, --csh-syntax,
>+--binary-syntax, or
>+--auto-syntax options. Several of these cause <command>dbus-launch</command> to emit shell code
>+to set up the environment.</para>
>+
>+<para>With the --auto-syntax option, <command>dbus-launch</command> looks at the value
>+of the SHELL environment variable to determine which shell syntax
>+should be used.  If SHELL ends in "csh", then csh-compatible code is
>+emitted; otherwise Bourne shell code is emitted.  Instead of passing
>+--auto-syntax, you may explicitly specify a particular one by using
>+--sh-syntax for Bourne syntax, or --csh-syntax for csh syntax.
>+In scripts, it's more robust to avoid --auto-syntax and you hopefully
>+know which shell your script is written in.</para>
>+
>+
>+<para>See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information
>+about D-Bus. See also the man page for <emphasis remap='I'>dbus-daemon</emphasis>.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='examples'><title>EXAMPLES</title>
>+<para>Distributions running
>+<command>dbus-launch</command>
>+as part of a standard X session should run
>+<emphasis remap='B'>dbus-launch --exit-with-session</emphasis>
>+after the X server has started and become available, as a wrapper around
>+the "main" X client (typically a session manager or window manager), as in
>+these examples:</para>
>+
>+  <blockquote remap='RS'>
>+<para><emphasis remap='B'>dbus-launch --exit-with-session gnome-session</emphasis></para>
>+
>+<para><emphasis remap='B'>dbus-launch --exit-with-session openbox</emphasis></para>
>+
>+<para><emphasis remap='B'>dbus-launch --exit-with-session ~/.xsession</emphasis>
>+  </para></blockquote> 
>+
>+<para>If your distribution does not do this, you can achieve similar results
>+by running your session or window manager in the same way in a script
>+run by your X session, such as
>+<filename>~/.xsession</filename>,
>+<filename>~/.xinitrc</filename>
>+or
>+<filename>~/.Xclients</filename>.</para>
>+
>+<para>To start a D-Bus session within a text-mode session, you can run
>+dbus-launch in the background. For instance, in a sh-compatible shell:</para>
>+
>+<literallayout remap='.nf'>
>+  ## test for an existing bus daemon, just to be safe
>+  if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
>+      ## if not found, launch a new one
>+      eval `dbus-launch --sh-syntax`
>+      echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS"
>+  fi
>+</literallayout> 
>+<para>Note that in this case, dbus-launch will exit, and dbus-daemon will not be
>+terminated automatically on logout.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='automatic_launching'><title>AUTOMATIC LAUNCHING</title>
>+<para>If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use
>+D-Bus, by default the process will attempt to invoke dbus-launch with
>+the --autolaunch option to start up a new session bus or find the 
>+existing bus address on the X display or in a file in
>+~/.dbus/session-bus/</para>
>+
>+
>+<para>Whenever an autolaunch occurs, the application that had to
>+start a new bus will be in its own little world; it can effectively
>+end up starting a whole new session if it tries to use a lot of 
>+bus services. This can be suboptimal or even totally broken, depending
>+on the app and what it tries to do.</para>
>+
>+
>+<para>There are two common reasons for autolaunch. One is ssh to a remote
>+machine. The ideal fix for that would be forwarding of
>+DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded.
>+In the meantime, you can edit the session.conf config file to 
>+have your session bus listen on TCP, and manually set
>+DBUS_SESSION_BUS_ADDRESS, if you like.</para>
>+
>+
>+<para>The second common reason for autolaunch is an su to another user, and
>+display of X applications running as the second user on the display
>+belonging to the first user. Perhaps the ideal fix in this case
>+would be to allow the second user to connect to the session bus of the
>+first user, just as they can connect to the first user's display.
>+However, a mechanism for that has not been coded.</para>
>+
>+
>+<para>You can always avoid autolaunch by manually setting
>+DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
>+address if none is set is "autolaunch:", so if any other address is
>+set there will be no autolaunch. You can however include autolaunch in
>+an explicit session bus address as a fallback, for example
>+DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
>+the first address doesn't work, processes will autolaunch. (The bus
>+address variable contains a comma-separated list of addresses to try.)</para>
>+
>+
>+<para>The --autolaunch option is considered an internal implementation
>+detail of libdbus, and in fact there are plans to change it. There's
>+no real reason to use it outside of the libdbus implementation anyhow.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<para>The following options are supported:</para>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--auto-syntax</option></term>
>+  <listitem>
>+<para>Choose --csh-syntax or --sh-syntax based on the SHELL environment variable.</para>
>+
>+<para><option>--binary-syntax</option>
>+Write to stdout a nul-terminated bus address, then the bus PID as a
>+binary integer of size sizeof(pid_t), then the bus X window ID as a
>+binary integer of size sizeof(long). Integers are in the machine's
>+byte order, not network byte order or any other canonical byte order.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--close-stderr</option></term>
>+  <listitem>
>+<para>Close the standard error output stream before starting the D-Bus
>+daemon. This is useful if you want to capture dbus-launch error
>+messages but you don't want dbus-daemon to keep the stream open to
>+your application.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--config-file=FILENAME</option></term>
>+  <listitem>
>+<para>Pass --config-file=FILENAME to the bus daemon, instead of passing it 
>+the --session argument. See the man page for dbus-daemon</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--csh-syntax</option></term>
>+  <listitem>
>+<para>Emit csh compatible code to set up environment variables.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--exit-with-session</option></term>
>+  <listitem>
>+<para>If this option is provided, a persistent "babysitter" process will be 
>+created that watches stdin for HUP and tries to connect to the X
>+server. If this process gets a HUP on stdin or loses its X connection,
>+it kills the message bus daemon.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--autolaunch=MACHINEID</option></term>
>+  <listitem>
>+<para>This option implies that <command>dbus-launch</command> should scan for a
>+previously-started session and reuse the values found there. If no
>+session is found, it will start a new session. The
>+--exit-with-session option is implied if --autolaunch is given.
>+This option is for the exclusive use of libdbus, you do not want to
>+use it manually. It may change in the future.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--sh-syntax</option></term>
>+  <listitem>
>+<para>Emit Bourne-shell compatible code to set up environment variables.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--version</option></term>
>+  <listitem>
>+<para>Print the version of dbus-launch</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='notes'><title>NOTES</title>
>+<para>If you run
>+<emphasis remap='B'>dbus-launch myapp</emphasis>
>+(with any other options), dbus-daemon will
>+<emphasis remap='I'>not</emphasis>
>+exit when
>+<emphasis remap='B'>myapp</emphasis>
>+terminates: this is because
>+<emphasis remap='B'>myapp</emphasis>
>+is assumed to be part of a larger session, rather than a session in its
>+own right.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>diff --git a/doc/dbus-launch.xml b/doc/dbus-launch.xml
>new file mode 100644
>index 0000000..dc34898
>--- /dev/null
>+++ b/doc/dbus-launch.xml
>@@ -0,0 +1,240 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
>+
>+<refentry id='dbuslaunch1'>
>+
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-launch</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv id='name'>
>+<refname>dbus-launch</refname>
>+<refpurpose>Utility to start a message bus from a shell script</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-launch</command>    <arg choice='opt'>--version </arg>
>+    <arg choice='opt'>--sh-syntax </arg>
>+    <arg choice='opt'>--csh-syntax </arg>
>+    <arg choice='opt'>--auto-syntax </arg>
>+    <arg choice='opt'>--exit-with-session </arg>
>+    <arg choice='opt'>--autolaunch=<replaceable>MACHINEID</replaceable></arg>
>+    <arg choice='opt'>--config-file=<replaceable>FILENAME</replaceable></arg>
>+    <arg choice='opt'><replaceable>PROGRAM</replaceable></arg>
>+    <arg choice='opt' rep='repeat'><replaceable>ARGS</replaceable></arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para>The <command>dbus-launch</command> command is used to start a session bus 
>+instance of <emphasis remap='I'>dbus-daemon</emphasis> from a shell script.
>+It would normally be called from a user's login
>+scripts. Unlike the daemon itself, <command>dbus-launch</command> exits, so
>+backticks or the $() construct can be used to read information from
>+<command>dbus-launch</command>.</para>
>+
>+<para>With no arguments, <command>dbus-launch</command> will launch a session bus
>+instance and print the address and pid of that instance to standard
>+output.</para>
>+
>+<para>You may specify a program to be run; in this case, <command>dbus-launch</command>
>+will launch a session bus instance, set the appropriate environment
>+variables so the specified program can find the bus, and then execute the
>+specified program, with the specified arguments.  See below for
>+examples.</para>
>+
>+<para>If you launch a program, <command>dbus-launch</command> will not print the
>+information about the new bus to standard output.</para>
>+
>+<para>When <command>dbus-launch</command> prints bus information to standard output, by
>+default it is in a simple key-value pairs format. However, you may 
>+request several alternate syntaxes using the --sh-syntax, --csh-syntax,
>+--binary-syntax, or
>+--auto-syntax options. Several of these cause <command>dbus-launch</command> to emit shell code
>+to set up the environment.</para>
>+
>+<para>With the --auto-syntax option, <command>dbus-launch</command> looks at the value
>+of the SHELL environment variable to determine which shell syntax
>+should be used.  If SHELL ends in "csh", then csh-compatible code is
>+emitted; otherwise Bourne shell code is emitted.  Instead of passing
>+--auto-syntax, you may explicity specify a particular one by using
>+--sh-syntax for Bourne syntax, or --csh-syntax for csh syntax.
>+In scripts, it's more robust to avoid --auto-syntax and you hopefully
>+know which shell your script is written in.</para>
>+
>+
>+<para>See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information
>+about D-Bus. See also the man page for <emphasis remap='I'>dbus-daemon</emphasis>.</para>
>+
>+
>+<para>Here is an example of how to use <command>dbus-launch</command> with an 
>+sh-compatible shell to start the per-session bus daemon:</para>
>+<literallayout remap='.nf'>
>+
>+  ## test for an existing bus daemon, just to be safe
>+  if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
>+      ## if not found, launch a new one
>+      eval `dbus-launch --sh-syntax --exit-with-session`
>+      echo "D-Bus per-session daemon address is: $DBUS_SESSION_BUS_ADDRESS"
>+  fi
>+
>+</literallayout> 
>+<para>You might run something like that in your login scripts.</para>
>+
>+
>+<para>Another way to use <command>dbus-launch</command> is to run your main session
>+program, like so:</para>
>+<literallayout remap='.nf'>
>+
>+dbus-launch gnome-session
>+
>+</literallayout> 
>+<para>The above would likely be appropriate for ~/.xsession or ~/.Xclients.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='automatic_launching'><title>AUTOMATIC LAUNCHING</title>
>+<para>If DBUS_SESSION_BUS_ADDRESS is not set for a process that tries to use
>+D-Bus, by default the process will attempt to invoke dbus-launch with
>+the --autolaunch option to start up a new session bus or find the 
>+existing bus address on the X display or in a file in
>+~/.dbus/session-bus/</para>
>+
>+
>+<para>Whenever an autolaunch occurs, the application that had to
>+start a new bus will be in its own little world; it can effectively
>+end up starting a whole new session if it tries to use a lot of 
>+bus services. This can be suboptimal or even totally broken, depending
>+on the app and what it tries to do.</para>
>+
>+
>+<para>There are two common reasons for autolaunch. One is ssh to a remote
>+machine. The ideal fix for that would be forwarding of
>+DBUS_SESSION_BUS_ADDRESS in the same way that DISPLAY is forwarded.
>+In the meantime, you can edit the session.conf config file to 
>+have your session bus listen on TCP, and manually set
>+DBUS_SESSION_BUS_ADDRESS, if you like.</para>
>+
>+
>+<para>The second common reason for autolaunch is an su to another user, and
>+display of X applications running as the second user on the display
>+belonging to the first user. Perhaps the ideal fix in this case
>+would be to allow the second user to connect to the session bus of the
>+first user, just as they can connect to the first user's display.
>+However, a mechanism for that has not been coded.</para>
>+
>+
>+<para>You can always avoid autolaunch by manually setting
>+DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
>+address if none is set is "autolaunch:", so if any other address is
>+set there will be no autolaunch. You can however include autolaunch in
>+an explicit session bus address as a fallback, for example
>+DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
>+the first address doesn't work, processes will autolaunch. (The bus
>+address variable contains a comma-separated list of addresses to try.)</para>
>+
>+
>+<para>The --autolaunch option is considered an internal implementation
>+detail of libdbus, and in fact there are plans to change it. There's
>+no real reason to use it outside of the libdbus implementation anyhow.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<para>The following options are supported:</para>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--auto-syntax</option></term>
>+  <listitem>
>+<para>Choose --csh-syntax or --sh-syntax based on the SHELL environment variable.</para>
>+
>+<para><option>--binary-syntax</option>
>+Write to stdout a nul-terminated bus address, then the bus PID as a
>+binary integer of size sizeof(pid_t), then the bus X window ID as a
>+binary integer of size sizeof(long). Integers are in the machine's
>+byte order, not network byte order or any other canonical byte order.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--close-stderr</option></term>
>+  <listitem>
>+<para>Close the standard error output stream before starting the D-Bus
>+daemon. This is useful if you want to capture dbus-launch error
>+messages but you don't want dbus-daemon to keep the stream open to
>+your application.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--config-file=FILENAME</option></term>
>+  <listitem>
>+<para>Pass --config-file=FILENAME to the bus daemon, instead of passing it 
>+the --session argument. See the man page for dbus-daemon</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--csh-syntax</option></term>
>+  <listitem>
>+<para>Emit csh compatible code to set up environment variables.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--exit-with-session</option></term>
>+  <listitem>
>+<para>If this option is provided, a persistent "babysitter" process will be 
>+created that watches stdin for HUP and tries to connect to the X
>+server. If this process gets a HUP on stdin or loses its X connection,
>+it kills the message bus daemon.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--autolaunch=MACHINEID</option></term>
>+  <listitem>
>+<para>This option implies that <command>dbus-launch</command> should scan for a
>+previously-started session and reuse the values found there. If no
>+session is found, it will start a new session. The
>+--exit-with-session option is implied if --autolaunch is given.
>+This option is for the exclusive use of libdbus, you do not want to
>+use it manually. It may change in the future.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--sh-syntax</option></term>
>+  <listitem>
>+<para>Emit Bourne-shell compatible code to set up environment variables.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--version</option></term>
>+  <listitem>
>+<para>Print the version of dbus-launch</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>diff --git a/doc/dbus-monitor.1.xml b/doc/dbus-monitor.1.xml
>new file mode 100644
>index 0000000..20e9301
>--- /dev/null
>+++ b/doc/dbus-monitor.1.xml
>@@ -0,0 +1,121 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
>+
>+<refentry id='dbusmonitor1'>
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-monitor</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv>
>+<refname>dbus-monitor</refname>
>+<refpurpose>debug probe to print message bus messages</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-monitor</command>    
>+    <group choice='opt'><arg choice='plain'>--system </arg><arg choice='plain'>--session </arg><arg choice='plain'>--address <replaceable>ADDRESS</replaceable></arg></group>
>+    <group choice='opt'><arg choice='plain'>--profile </arg><arg choice='plain'>--monitor </arg></group>
>+    <arg choice='opt'><arg choice='plain'><replaceable>watch</replaceable></arg><arg choice='plain'><replaceable>expressions</replaceable></arg></arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para>The <command>dbus-monitor</command> command is used to monitor messages going
>+through a D-Bus message bus.  See
>+<ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about
>+the big picture.</para>
>+
>+
>+<para>There are two well-known message buses: the systemwide message bus
>+(installed on many systems as the "messagebus" service) and the
>+per-user-login-session message bus (started each time a user logs in).
>+The --system and --session options direct <command>dbus-monitor</command> to
>+monitor the system or session buses respectively.  If neither is
>+specified, <command>dbus-monitor</command> monitors the session bus.</para>
>+
>+
>+<para><command>dbus-monitor</command> has two different output modes, the 'classic'-style
>+monitoring mode and profiling mode. The profiling format is a compact
>+format with a single line per message and microsecond-resolution timing
>+information. The --profile and --monitor options select the profiling
>+and monitoring output format respectively. If neither is specified,
>+<command>dbus-monitor</command> uses the monitoring output format.</para>
>+
>+
>+<para>In order to get <command>dbus-monitor</command> to see the messages you are interested
>+in, you should specify a set of watch expressions as you would expect to
>+be passed to the <emphasis remap='I'>dbus_bus_add_match</emphasis> function.</para>
>+
>+
>+<para>The message bus configuration may keep <command>dbus-monitor</command> from seeing
>+all messages, especially if you run the monitor as a non-root user.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--system</option></term>
>+  <listitem>
>+<para>Monitor the system message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--session</option></term>
>+  <listitem>
>+<para>Monitor the session message bus.  (This is the default.)</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--address ADDRESS</option></term>
>+  <listitem>
>+<para>Monitor an arbitrary message bus given at ADDRESS.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--profile</option></term>
>+  <listitem>
>+<para>Use the profiling output format.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--monitor</option></term>
>+  <listitem>
>+<para>Use the monitoring output format.  (This is the default.)</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='example'><title>EXAMPLE</title>
>+<para>Here is an example of using dbus-monitor to watch for the gnome typing
>+monitor to say things</para>
>+<literallayout remap='.nf'>
>+
>+  dbus-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'"
>+
>+</literallayout> 
>+
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>dbus-monitor was written by Philip Blundell.
>+The profiling output mode was added by Olli Salli.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>diff --git a/doc/dbus-monitor.xml b/doc/dbus-monitor.xml
>new file mode 100644
>index 0000000..b41cace
>--- /dev/null
>+++ b/doc/dbus-monitor.xml
>@@ -0,0 +1,121 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
>+
>+<refentry id='dbusmonitor1'>
>+
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-monitor</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv id='name'>
>+<refname>dbus-monitor</refname>
>+<refpurpose>debug probe to print message bus messages</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-monitor</command>    
>+    <group choice='opt'><arg choice='plain'>--system </arg><arg choice='plain'>--session </arg><arg choice='plain'>--address <replaceable>ADDRESS</replaceable></arg></group>
>+    <group choice='opt'><arg choice='plain'>--profile </arg><arg choice='plain'>--monitor </arg></group>
>+    <arg choice='opt'><arg choice='plain'><replaceable>watch</replaceable></arg><arg choice='plain'><replaceable>expressions</replaceable></arg></arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para>The <command>dbus-monitor</command> command is used to monitor messages going
>+through a D-Bus message bus.  See
>+<ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information about
>+the big picture.</para>
>+
>+
>+<para>There are two well-known message buses: the systemwide message bus
>+(installed on many systems as the "messagebus" service) and the
>+per-user-login-session message bus (started each time a user logs in).
>+The --system and --session options direct <command>dbus-monitor</command> to
>+monitor the system or session buses respectively.  If neither is
>+specified, <command>dbus-monitor</command> monitors the session bus.</para>
>+
>+
>+<para><command>dbus-monitor</command> has two different output modes, the 'classic'-style
>+monitoring mode and profiling mode. The profiling format is a compact
>+format with a single line per message and microsecond-resolution timing
>+information. The --profile and --monitor options select the profiling
>+and monitoring output format respectively. If neither is specified,
>+<command>dbus-monitor</command> uses the monitoring output format.</para>
>+
>+
>+<para>In order to get <command>dbus-monitor</command> to see the messages you are interested
>+in, you should specify a set of watch expressions as you would expect to
>+be passed to the <emphasis remap='I'>dbus_bus_add_match</emphasis> function.</para>
>+
>+
>+<para>The message bus configuration may keep <command>dbus-monitor</command> from seeing
>+all messages, especially if you run the monitor as a non-root user.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--system</option></term>
>+  <listitem>
>+<para>Monitor the system message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--session</option></term>
>+  <listitem>
>+<para>Monitor the session message bus.  (This is the default.)</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--address ADDRESS</option></term>
>+  <listitem>
>+<para>Monitor an arbitrary message bus given at ADDRESS.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--profile</option></term>
>+  <listitem>
>+<para>Use the profiling output format.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--monitor</option></term>
>+  <listitem>
>+<para>Use the monitoring output format.  (This is the default.)</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='example'><title>EXAMPLE</title>
>+<para>Here is an example of using dbus-monitor to watch for the gnome typing
>+monitor to say things</para>
>+<literallayout remap='.nf'>
>+
>+  dbus-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'"
>+
>+</literallayout> 
>+
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>dbus-monitor was written by Philip Blundell.
>+The profiling output mode was added by Olli Salli.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>diff --git a/doc/dbus-send.1.xml b/doc/dbus-send.1.xml
>new file mode 100644
>index 0000000..30d57c5
>--- /dev/null
>+++ b/doc/dbus-send.1.xml
>@@ -0,0 +1,157 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
>+
>+<refentry id='dbussend1'>
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-send</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv>
>+<refname>dbus-send</refname>
>+<refpurpose>Send a message to a message bus</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-send</command>    
>+    <group choice='opt'><arg choice='plain'>--system </arg><arg choice='plain'>--session </arg></group>
>+    <arg choice='opt'>--dest=<replaceable>NAME</replaceable></arg>
>+    <arg choice='opt'><arg choice='plain'>--print-reply </arg><arg choice='opt'><replaceable>=literal</replaceable></arg></arg>
>+    <arg choice='opt'>--reply-timeout=<replaceable>MSEC</replaceable></arg>
>+    <arg choice='opt'>--type=<replaceable>TYPE</replaceable></arg>
>+    <arg choice='plain'><replaceable>OBJECT_PATH</replaceable></arg>
>+    <arg choice='plain'><replaceable>INTERFACE.MEMBER</replaceable></arg>
>+    <arg choice='opt' rep='repeat'><replaceable>CONTENTS</replaceable></arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para>The <command>dbus-send</command> command is used to send a message to a D-Bus message
>+bus. See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more 
>+information about the big picture.</para>
>+
>+
>+<para>There are two well-known message buses: the systemwide message bus 
>+(installed on many systems as the "messagebus" service) and the 
>+per-user-login-session message bus (started each time a user logs in).
>+The <option>--system</option> and <option>--session</option> options direct
>+<command>dbus-send</command> to send messages to the system or session buses respectively.
>+If neither is specified, <command>dbus-send</command> sends to the session bus.</para>
>+
>+
>+<para>Nearly all uses of <command>dbus-send</command> must provide the <option>--dest</option> argument
>+which is the name of a connection on the bus to send the message to. If
>+<option>--dest</option> is omitted, no destination is set.</para>
>+
>+
>+<para>The object path and the name of the message to send must always be
>+specified. Following arguments, if any, are the message contents
>+(message arguments).  These are given as type-specified values and 
>+may include containers (arrays, dicts, and variants) as described below.</para>
>+
>+<literallayout remap='.nf'>
>+&lt;contents&gt;   ::= &lt;item&gt; | &lt;container&gt; [ &lt;item&gt; | &lt;container&gt;...]
>+&lt;item&gt;       ::= &lt;type&gt;:&lt;value&gt;
>+&lt;container&gt;  ::= &lt;array&gt; | &lt;dict&gt; | &lt;variant&gt;
>+&lt;array&gt;      ::= array:&lt;type&gt;:&lt;value&gt;[,&lt;value&gt;...] 
>+&lt;dict&gt;       ::= dict:&lt;type&gt;:&lt;type&gt;:&lt;key&gt;,&lt;value&gt;[,&lt;key&gt;,&lt;value&gt;...]
>+&lt;variant&gt;    ::= variant:&lt;type&gt;:&lt;value&gt;
>+&lt;type&gt;       ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath
>+</literallayout> 
>+
>+<para>D-Bus supports more types than these, but <command>dbus-send</command> currently
>+does not.  Also, <command>dbus-send</command> does not permit empty containers
>+or nested containers (e.g. arrays of variants).</para>
>+
>+
>+<para>Here is an example invocation:</para>
>+<literallayout remap='.nf'>
>+
>+  dbus-send --dest=org.freedesktop.ExampleName               &bsol;
>+            /org/freedesktop/sample/object/name              &bsol;
>+            org.freedesktop.ExampleInterface.ExampleMethod   &bsol;
>+            int32:47 string:'hello world' double:65.32       &bsol;
>+            array:string:"1st item","next item","last item"  &bsol;
>+            dict:string:int32:"one",1,"two",2,"three",3      &bsol;
>+            variant:int32:-8                                 &bsol;
>+            objpath:/org/freedesktop/sample/object/name 
>+
>+</literallayout> 
>+
>+<para>Note that the interface is separated from a method or signal 
>+name by a dot, though in the actual protocol the interface
>+and the interface member are separate fields.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<para>The following options are supported:</para>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--dest=</option><replaceable>NAME</replaceable></term>
>+  <listitem>
>+<para>Specify the name of the connection to receive the message.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--print-reply</option></term>
>+  <listitem>
>+<para>Block for a reply to the message sent, and print any reply received
>+in a human-readable form.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--print-reply=literal</option></term>
>+  <listitem>
>+<para>Block for a reply to the message sent, and print the body of the
>+reply. If the reply is an object path or a string, it is printed
>+literally, with no punctuation, escape characters etc.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--reply-timeout=</option><replaceable>MSEC</replaceable></term>
>+  <listitem>
>+<para>Wait for a reply for up to <emphasis remap='I'>MSEC</emphasis> milliseconds.
>+The default is implementation&hyphen;defined, typically 25 seconds.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--system</option></term>
>+  <listitem>
>+<para>Send to the system message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--session</option></term>
>+  <listitem>
>+<para>Send to the session message bus.  (This is the default.)</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--type=</option><replaceable>TYPE</replaceable></term>
>+  <listitem>
>+<para>Specify <emphasis remap='B'>method_call</emphasis> or <emphasis remap='B'>signal</emphasis> (defaults to "<emphasis remap='B'>signal</emphasis>").</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>dbus-send was written by Philip Blundell.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>diff --git a/doc/dbus-send.xml b/doc/dbus-send.xml
>new file mode 100644
>index 0000000..7fefc03
>--- /dev/null
>+++ b/doc/dbus-send.xml
>@@ -0,0 +1,143 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
>+
>+<refentry id='dbussend1'>
>+
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-send</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv id='name'>
>+<refname>dbus-send</refname>
>+<refpurpose>Send a message to a message bus</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-send</command>    
>+    <group choice='opt'><arg choice='plain'>--system </arg><arg choice='plain'>--session </arg></group>
>+    <arg choice='opt'>--dest=<replaceable>NAME</replaceable></arg>
>+    <arg choice='opt'>--print-reply </arg>
>+    <arg choice='opt'>--type=<replaceable>TYPE</replaceable></arg>
>+    <arg choice='plain'><replaceable>&lt;destination</replaceable></arg>
>+    <arg choice='plain'><replaceable>object</replaceable></arg>
>+    <arg choice='plain'><replaceable>path&gt;</replaceable></arg>
>+    <arg choice='plain'><replaceable>&lt;message</replaceable></arg>
>+    <arg choice='plain'><replaceable>name&gt;</replaceable></arg>
>+    <arg choice='opt' rep='repeat'><replaceable>contents</replaceable></arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para>The <command>dbus-send</command> command is used to send a message to a D-Bus message
>+bus. See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more 
>+information about the big picture.</para>
>+
>+
>+<para>There are two well-known message buses: the systemwide message bus 
>+(installed on many systems as the "messagebus" service) and the 
>+per-user-login-session message bus (started each time a user logs in).
>+The --system and --session options direct <command>dbus-send</command> to send
>+messages to the system or session buses respectively.  If neither is
>+specified, <command>dbus-send</command> sends to the session bus.</para>
>+
>+
>+<para>Nearly all uses of <command>dbus-send</command> must provide the --dest argument
>+which is the name of a connection on the bus to send the message to. If
>+--dest is omitted, no destination is set.</para>
>+
>+
>+<para>The object path and the name of the message to send must always be
>+specified. Following arguments, if any, are the message contents
>+(message arguments).  These are given as type-specified values and 
>+may include containers (arrays, dicts, and variants) as described below.</para>
>+
>+<literallayout remap='.nf'>
>+&lt;contents&gt;   ::= &lt;item&gt; | &lt;container&gt; [ &lt;item&gt; | &lt;container&gt;...]
>+&lt;item&gt;       ::= &lt;type&gt;:&lt;value&gt;
>+&lt;container&gt;  ::= &lt;array&gt; | &lt;dict&gt; | &lt;variant&gt;
>+&lt;array&gt;      ::= array:&lt;type&gt;:&lt;value&gt;[,&lt;value&gt;...] 
>+&lt;dict&gt;       ::= dict:&lt;type&gt;:&lt;type&gt;:&lt;key&gt;,&lt;value&gt;[,&lt;key&gt;,&lt;value&gt;...]
>+&lt;variant&gt;    ::= variant:&lt;type&gt;:&lt;value&gt;
>+&lt;type&gt;       ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath
>+</literallayout> 
>+
>+<para>D-Bus supports more types than these, but <command>dbus-send</command> currently
>+does not.  Also, <command>dbus-send</command> does not permit empty containers
>+or nested containers (e.g. arrays of variants).</para>
>+
>+
>+<para>Here is an example invocation:</para>
>+<literallayout remap='.nf'>
>+
>+  dbus-send --dest=org.freedesktop.ExampleName               \
>+            /org/freedesktop/sample/object/name              \
>+            org.freedesktop.ExampleInterface.ExampleMethod   \
>+            int32:47 string:'hello world' double:65.32       \
>+            array:string:"1st item","next item","last item"  \
>+            dict:string:int32:"one",1,"two",2,"three",3      \
>+            variant:int32:-8                                 \
>+            objpath:/org/freedesktop/sample/object/name 
>+
>+</literallayout> 
>+
>+<para>Note that the interface is separated from a method or signal 
>+name by a dot, though in the actual protocol the interface
>+and the interface member are separate fields.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<para>The following options are supported:</para>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--dest=NAME</option></term>
>+  <listitem>
>+<para>Specify the name of the connection to receive the message.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--print-reply</option></term>
>+  <listitem>
>+<para>Block for a reply to the message sent, and print any reply received.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--system</option></term>
>+  <listitem>
>+<para>Send to the system message bus.</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--session</option></term>
>+  <listitem>
>+<para>Send to the session message bus.  (This is the default.)</para>
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--type=TYPE</option></term>
>+  <listitem>
>+<para>Specify "method_call" or "signal" (defaults to "signal").</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>dbus-send was written by Philip Blundell.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>diff --git a/doc/dbus-uuidgen.1.xml b/doc/dbus-uuidgen.1.xml
>new file mode 100644
>index 0000000..3d99ef8
>--- /dev/null
>+++ b/doc/dbus-uuidgen.1.xml
>@@ -0,0 +1,125 @@
>+<?xml version="1.0" encoding="ISO-8859-1"?>
>+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
>+                   "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
>+
>+<refentry id='dbusuuidgen1'>
>+
>+
>+
>+<refmeta>
>+<refentrytitle>dbus-uuidgen</refentrytitle>
>+<manvolnum>1</manvolnum>
>+</refmeta>
>+<refnamediv>
>+<refname>dbus-uuidgen</refname>
>+<refpurpose>Utility to generate UUIDs</refpurpose>
>+</refnamediv>
>+
>+<refsynopsisdiv id='synopsis'>
>+<cmdsynopsis>
>+  <command>dbus-uuidgen</command>    <arg choice='opt'>--version </arg>
>+    <arg choice='opt'><arg choice='plain'>--ensure </arg><arg choice='opt'><replaceable>=FILENAME</replaceable></arg></arg>
>+    <arg choice='opt'><arg choice='plain'>--get </arg><arg choice='opt'><replaceable>=FILENAME</replaceable></arg></arg>
>+    <sbr/>
>+</cmdsynopsis>
>+</refsynopsisdiv>
>+
>+
>+<refsect1 id='description'><title>DESCRIPTION</title>
>+<para>The <command>dbus-uuidgen</command> command generates or reads a universally unique ID.</para>
>+
>+
>+<para>Note that the D-Bus UUID has no relationship to RFC 4122 and does not generate
>+UUIDs compatible with that spec. Many systems have a separate command
>+for that (often called "uuidgen").</para>
>+
>+
>+<para>See <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink> for more information
>+about D-Bus.</para>
>+
>+
>+<para>The primary usage of <command>dbus-uuidgen</command> is to run in the post-install
>+script of a D-Bus package like this:</para>
>+<literallayout remap='.nf'>
>+  dbus-uuidgen --ensure
>+</literallayout> 
>+
>+
>+<para>This will ensure that /var/lib/dbus/machine-id exists and has the uuid in it.
>+It won't overwrite an existing uuid, since this id should remain fixed
>+for a single machine until the next reboot at least.</para>
>+
>+
>+<para>The important properties of the machine UUID are that 1) it remains
>+unchanged until the next reboot and 2) it is different for any two 
>+running instances of the OS kernel. That is, if two processes see the 
>+same UUID, they should also see the same shared memory, UNIX domain
>+sockets, local X displays, localhost.localdomain resolution, process
>+IDs, and so forth.</para>
>+
>+
>+<para>If you run <command>dbus-uuidgen</command> with no options it just prints a new uuid made
>+up out of thin air.</para>
>+
>+
>+<para>If you run it with --get, it prints the machine UUID by default, or
>+the UUID in the specified file if you specify a file.</para>
>+
>+
>+<para>If you try to change an existing machine-id on a running system, it will
>+probably result in bad things happening. Don't try to change this file. Also,
>+don't make it the same on two different systems; it needs to be different
>+anytime there are two different kernels running.</para>
>+
>+
>+<para>The UUID should be different on two different virtual machines,
>+because there are two different kernels.</para>
>+
>+</refsect1>
>+
>+<refsect1 id='options'><title>OPTIONS</title>
>+<para>The following options are supported:</para>
>+<variablelist remap='TP'>
>+  <varlistentry>
>+  <term><option>--get[=FILENAME]</option></term>
>+  <listitem>
>+<para>If a filename is not given, defaults to localstatedir/lib/dbus/machine-id
>+(localstatedir is usually /var). If this file exists and is valid, the
>+uuid in the file is printed on stdout. Otherwise, the command exits 
>+with a nonzero status.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--ensure[=FILENAME]</option></term>
>+  <listitem>
>+<para>If a filename is not given, defaults to localstatedir/lib/dbus/machine-id
>+(localstatedir is usually /var). If this file exists then it will be
>+validated, and a failure code returned if it contains the wrong thing.
>+If the file does not exist, it will be created with a new uuid in it.
>+On success, prints no output.</para>
>+
>+  </listitem>
>+  </varlistentry>
>+  <varlistentry>
>+  <term><option>--version</option></term>
>+  <listitem>
>+<para>Print the version of dbus-uuidgen</para>
>+
>+  </listitem>
>+  </varlistentry>
>+</variablelist>
>+</refsect1>
>+
>+<refsect1 id='author'><title>AUTHOR</title>
>+<para>See <ulink url='http://www.freedesktop.org/software/dbus/doc/AUTHORS'>http://www.freedesktop.org/software/dbus/doc/AUTHORS</ulink></para>
>+
>+</refsect1>
>+
>+<refsect1 id='bugs'><title>BUGS</title>
>+<para>Please send bug reports to the D-Bus mailing list or bug tracker,
>+see <ulink url='http://www.freedesktop.org/software/dbus/'>http://www.freedesktop.org/software/dbus/</ulink></para>
>+</refsect1>
>+</refentry>
>+
>-- 
>1.7.10.4
>

Actions: View | Splinter Review

Attachments on bug 59805: 74208 | 74209 | 74210 | 74212 | 74213 | 74214 | 74216 | 74691 | 74693 | 74695 | 74696 | 74812 | 74813 | 75325 | 75384

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.