Merge branch 'documentation-build-system'

8 files changed, 1345 insertions, 14 deletions

diff --git a/doc/.gitignore b/doc/.gitignore
index 3430689c..fd193572 100644
--- a/doc/.gitignore
+++ b/doc/.gitignore
@@ -2,6 +2,7 @@
 .libs
 Makefile
 Makefile.in
+*.1.html
 *.lo
 *.la
 *.o
@@ -10,3 +11,6 @@ dbus-specification.html
 dbus-test-plan.html
 dbus-tutorial.html
 dbus-faq.html
+dbus-daemon.1
+dbus-docs
+dbus-docs.tar.gz
diff --git a/doc/Makefile.am b/doc/Makefile.am
index f76335f6..bc349f87 100644
--- a/doc/Makefile.am
+++ b/doc/Makefile.am
@@ -1,16 +1,41 @@
-EXTRA_DIST= 					\
-	busconfig.dtd				\
-	diagram.png				\
-	diagram.svg				\
-	introspect.dtd				\
-	dbus-faq.xml				\
-	dbus-specification.xml			\
-	dbus-test-plan.xml			\
-	dbus-tutorial.xml			\
-	dcop-howto.txt				\
-	file-boilerplate.c			\
-	introspect.xsl				\
-	system-activation.txt
+man_MANS = \
+	dbus-cleanup-sockets.1 \
+	dbus-daemon.1 \
+	dbus-launch.1 \
+	dbus-monitor.1 \
+	dbus-send.1 \
+	dbus-uuidgen.1
+
+MAN_IN_FILES = dbus-daemon.1.in
+
+MAN_HTML_FILES = \
+	dbus-cleanup-sockets.1.html \
+	dbus-daemon.1.html \
+	dbus-launch.1.html \
+	dbus-monitor.1.html \
+	dbus-send.1.html \
+	dbus-uuidgen.1.html
+
+DTDS = \
+	busconfig.dtd \
+	introspect.dtd
+
+STATIC_DOCS = \
+	diagram.png \
+	diagram.svg \
+	dbus-faq.xml \
+	dbus-specification.xml \
+	dbus-test-plan.xml \
+	dbus-tutorial.xml \
+	dcop-howto.txt \
+	introspect.xsl \
+	system-activation.txt \
+	$(DTDS)
+
+EXTRA_DIST = \
+	file-boilerplate.c \
+	$(STATIC_DOCS) \
+	$(MAN_IN_FILES) $(man_MANS)
 
 HTML_FILES=					\
 	dbus-faq.html				\
@@ -19,7 +44,7 @@ HTML_FILES=					\
 	dbus-tutorial.html
 
 if DBUS_XML_DOCS_ENABLED
-all-local: $(HTML_FILES)
+all-local:: $(HTML_FILES)
 
 EXTRA_DIST += $(HTML_FILES)
 
@@ -37,5 +62,67 @@ dbus-faq.html: dbus-faq.xml
 
 endif
 
+if DBUS_DOXYGEN_DOCS_ENABLED
+# Use the index as a proxy for the entire doc tree.
+DOXYGEN_HTML_INDEX = api/html/index.html
+
+all-local:: $(DOXYGEN_HTML_INDEX)
+
+$(DOXYGEN_HTML_INDEX): $(wildcard $(top_srcdir)/dbus/*.[ch])
+	$(AM_V_GEN)cd $(top_builddir) && doxygen Doxyfile
+endif
+
+if DBUS_HAVE_MAN2HTML
+all-local:: $(MAN_HTML_FILES)
+
+%.1.html: %.1
+	$(AM_V_GEN)( $(MAN2HTML) $< > $@.tmp && mv $@.tmp $@ )
+endif
+
+if DBUS_CAN_UPLOAD_DOCS
+BONUS_FILES = \
+	$(top_srcdir)/README \
+	$(top_srcdir)/HACKING \
+	$(top_srcdir)/AUTHORS \
+	$(top_srcdir)/NEWS \
+	$(top_srcdir)/COPYING \
+	$(top_srcdir)/ChangeLog
+
+dbus-docs: $(STATIC_DOCS) $(HTML_FILES) $(MAN_HTML_FILES) $(BONUS_FILES) $(DOXYGEN_HTML_INDEX)
+	$(AM_V_at)rm -rf $@
+	$(AM_V_GEN)mkdir -p $@/api
+	$(AM_V_at)cp $(STATIC_DOCS) $@
+	$(AM_V_at)cp $(HTML_FILES) $@
+	$(AM_V_at)cp $(MAN_HTML_FILES) $@
+	$(AM_V_at)cp $(BONUS_FILES) $@
+	$(AM_V_at)cp -r api/html $@/api
+
+dbus-docs.tar.gz: dbus-docs
+	$(AM_V_GEN)tar czf $@ $<
+
+DOC_SERVER = dbus.freedesktop.org
+DOC_WWW_DIR = /srv/dbus.freedesktop.org/www
+
+SPECIFICATION_SERVER = specifications.freedesktop.org
+SPECIFICATION_PATH = /srv/specifications.freedesktop.org/www/dbus/1.0
+
+maintainer-upload-docs: dbus-docs.tar.gz dbus-docs
+	scp dbus-docs.tar.gz $(DOC_SERVER):$(DOC_WWW_DIR)
+	rsync -rvzP --chmod=Dg+s,ug+rwX,o=rX \
+		dbus-docs/ $(DOC_SERVER):$(DOC_WWW_DIR)/doc/
+	scp -p $(DTDS) $(SPECIFICATION_SERVER):$(SPECIFICATION_PATH)
+else
+maintainer-upload-docs:
+	@echo "Can't upload documentation! Re-run configure with"
+	@echo "  --enable-doxygen-docs --enable-xml-docs"
+	@echo "and ensure that man2html is installed."
+	@false
+endif
+
+clean-local:
+	rm -rf api
+	rm -rf dbus-docs
+	rm -f *.1.html
+
 maintainer-clean-local:
 	rm -f $(HTML_FILES)
diff --git a/doc/dbus-cleanup-sockets.1 b/doc/dbus-cleanup-sockets.1
new file mode 100644
index 00000000..ca669f49
--- /dev/null
+++ b/doc/dbus-cleanup-sockets.1
@@ -0,0 +1,43 @@
+.\" 
+.\" dbus-cleanup-sockets manual page.
+.\" Copyright (C) 2003 Red Hat, Inc.
+.\"
+.TH dbus-cleanup-sockets 1
+.SH NAME
+dbus-cleanup-sockets \- clean up leftover sockets in a directory
+.SH SYNOPSIS
+.PP
+.B dbus-cleanup-sockets [DIRECTORY]
+
+.SH DESCRIPTION
+
+The \fIdbus-cleanup-sockets\fP command cleans up unused D-Bus
+connection sockets. See http://www.freedesktop.org/software/dbus/ for
+more information about the big picture.
+
+.PP
+If given no arguments, \fIdbus-cleanup-sockets\fP cleans up sockets 
+in the standard default socket directory for the
+per-user-login-session message bus; this is usually /tmp. 
+Optionally, you can pass a different directory on the command line.
+
+.PP
+On Linux, this program is essentially useless, because D-Bus defaults
+to using "abstract sockets" that exist only in memory and don't have a
+corresponding file in /tmp. 
+
+.PP
+On most other flavors of UNIX, it's possible for the socket files to
+leak when programs using D-Bus exit abnormally or without closing
+their D-Bus connections. Thus, it might be interesting to run
+dbus-cleanup-sockets in a cron job to mop up any leaked sockets.
+Or you can just ignore the leaked sockets, they aren't really hurting
+anything, other than cluttering the output of "ls /tmp"
+
+.SH AUTHOR
+dbus-cleanup-sockets was adapted by Havoc Pennington from
+linc-cleanup-sockets written by Michael Meeks.
+
+.SH BUGS
+Please send bug reports to the D-Bus mailing list or bug tracker,
+see http://www.freedesktop.org/software/dbus/
diff --git a/doc/dbus-daemon.1.in b/doc/dbus-daemon.1.in
new file mode 100644
index 00000000..a54f8634
--- /dev/null
+++ b/doc/dbus-daemon.1.in
@@ -0,0 +1,752 @@
+.\"
+.\" dbus-daemon manual page.
+.\" Copyright (C) 2003,2008 Red Hat, Inc.
+.\"
+.TH dbus-daemon 1
+.SH NAME
+dbus-daemon \- Message bus daemon
+.SH SYNOPSIS
+.PP
+.B dbus-daemon
+dbus-daemon [\-\-version] [\-\-session] [\-\-system] [\-\-config-file=FILE]
+[\-\-print-address[=DESCRIPTOR]] [\-\-print-pid[=DESCRIPTOR]] [\-\-fork]
+
+.SH DESCRIPTION
+\fIdbus-daemon\fP is the D-Bus message bus daemon. See
+http://www.freedesktop.org/software/dbus/ for more information about
+the big picture. D-Bus is first a library that provides one-to-one
+communication between any two applications; \fIdbus-daemon\fP 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.
+.PP
+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).
+\fIdbus-daemon\fP is used for both of these instances, but with
+a different configuration file.
+.PP
+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.
+.PP
+The systemwide daemon is normally launched by an init script,
+standardly called simply "messagebus".
+.PP
+The systemwide daemon is largely used for broadcasting system events,
+such as changes to the printer queue, or adding/removing devices.
+.PP
+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).
+.PP
+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.
+
+.SH OPTIONS
+The following options are supported:
+.TP
+.I "--config-file=FILE"
+Use the given configuration file.
+.TP
+.I "--fork"
+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.
+.I "--nofork"
+Force the message bus not to fork and become a daemon, even if
+the configuration file specifies that it should.
+.TP
+.I "--print-address[=DESCRIPTOR]"
+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.
+.TP
+.I "--print-pid[=DESCRIPTOR]"
+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.
+.TP
+.I "--session"
+Use the standard configuration file for the per-login-session message
+bus.
+.TP
+.I "--system"
+Use the standard configuration file for the systemwide message bus.
+.TP
+.I "--version"
+Print the version of the daemon.
+.TP
+.I "--introspect"
+Print the introspection information for all D-Bus internal interfaces.
+.TP
+.I "--address[=ADDRESS]"
+Set the address to listen on. This option overrides the address
+configured in the configuration file.
+.TP
+.I "--systemd-activation"
+Enable systemd-style service activation. Only useful in conjunction
+with the systemd system and session manager on Linux.
+
+.SH CONFIGURATION FILE
+
+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.
+.PP
+The configuration file also establishes resource limits, security
+parameters, and so forth.
+.PP
+The configuration file is not part of any interoperability
+specification and its backward compatibility is not guaranteed; this
+document is documentation, not specification.
+.PP
+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
+<include> a system-local.conf or session-local.conf; you can put local
+overrides in those files to avoid modifying the primary configuration
+files.
+
+.PP
+The configuration file is an XML document. It must have the following
+doctype declaration:
+.nf
+
+   <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
+    "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
+
+.fi
+
+.PP
+The following elements may be present in the configuration file.
+
+.TP
+.I "<busconfig>"
+
+.PP
+Root element.
+
+.TP
+.I "<type>"
+
+.PP
+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
+<type> 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.
+
+.PP
+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).
+
+.PP
+Example: <type>session</type>
+
+.TP
+.I "<include>"
+
+.PP
+Include a file <include>filename.conf</include> at this point.  If the
+filename is relative, it is located relative to the configuration file
+doing the including.
+
+.PP
+<include> 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.
+
+.TP
+.I "<includedir>"
+
+.PP
+Include all files in <includedir>foo.d</includedir> at this
+point. Files in the directory are included in undefined order.
+Only files ending in ".conf" are included.
+
+.PP
+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.
+
+.TP
+.I "<user>"
+
+.PP
+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.
+
+.PP
+The last <user> entry in the file "wins", the others are ignored.
+
+.PP
+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.
+
+.TP
+.I "<fork>"
+
+.PP
+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.
+
+.TP
+.I "<keep_umask>"
+
+.PP
+If present, the bus daemon keeps its original umask when forking.
+This may be useful to avoid affecting the behavior of child processes.
+
+.TP
+.I "<listen>"
+
+.PP
+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.
+
+.PP
+Example: <listen>unix:path=/tmp/foo</listen>
+
+.PP
+Example: <listen>tcp:host=localhost,port=1234</listen>
+
+.PP
+If there are multiple <listen> 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 <listen> first. That is,
+apps will try to connect to the last <listen> address first.
+
+.PP
+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
+
+.PP
+Example: <listen>tcp:host=localhost,port=0,family=ipv4</listen>
+
+.PP
+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.
+
+.PP
+Example: <listen>tcp:host=localhost,port=0</listen>
+
+.PP
+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.
+
+.PP
+Example: <listen>tcp:host=localhost,bind=*,port=0</listen>
+
+.TP
+.I "<auth>"
+
+.PP
+Lists permitted authorization mechanisms. If this element doesn't
+exist, then all known mechanisms are allowed.  If there are multiple
+<auth> elements, all the listed mechanisms are allowed.  The order in
+which mechanisms are listed is not meaningful.
+
+.PP
+Example: <auth>EXTERNAL</auth>
+
+.PP
+Example: <auth>DBUS_COOKIE_SHA1</auth>
+
+.TP
+.I "<servicedir>"
+
+.PP
+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).
+
+.PP
+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.
+
+.TP
+.I "<standard_session_servicedirs/>"
+
+.PP
+<standard_session_servicedirs/> is equivalent to specifying a series
+of <servicedir/> 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.
+
+.PP
+The "XDG Base Directory Specification" can be found at
+http://freedesktop.org/wiki/Standards/basedir-spec if it hasn't moved,
+otherwise try your favorite search engine.
+
+.PP
+The <standard_session_servicedirs/> 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.
+
+.TP
+.I "<standard_system_servicedirs/>"
+
+.PP
+<standard_system_servicedirs/> specifies the standard system-wide
+activation directories that should be searched for service files.
+This option defaults to @EXPANDED_DATADIR@/dbus-1/system-services.
+
+.PP
+The <standard_system_servicedirs/> 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.
+
+.TP
+.I "<servicehelper/>"
+
+.PP
+<servicehelper/> 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.
+
+.PP
+The <servicehelper/> 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.
+
+.TP
+.I "<limit>"
+
+.PP
+<limit> establishes a resource limit. For example:
+.nf
+  <limit name="max_message_size">64</limit>
+  <limit name="max_completed_connections">512</limit>
+.fi
+
+.PP
+The name attribute is mandatory.
+Available limit names are:
+.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
+.fi
+
+.PP
+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.
+
+.PP
+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.
+
+.PP
+Limits are normally only of interest on the systemwide bus, not the user session
+buses.
+
+.TP
+.I "<policy>"
+
+.PP
+The <policy> element defines a security policy to be applied to a particular
+set of connections to the bus. A policy is made up of
+<allow> and <deny> 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.
+
+.PP
+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.
+
+.PP
+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 <allow> 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.
+
+.PP
+The <policy> element has one of four attributes:
+.nf
+  context="(default|mandatory)"
+  at_console="(true|false)"
+  user="username or userid"
+  group="group name or gid"
+.fi
+
+.PP
+Policies are applied to a connection as follows:
+.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
+.fi
+
+.PP
+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.
+
+.TP
+.I "<deny>"
+.I "<allow>"
+
+.PP
+A <deny> element appears below a <policy> element and prohibits some
+action. The <allow> element makes an exception to previous <deny>
+statements, and works just like <deny> but with the inverse meaning.
+
+.PP
+The possible attributes of these elements are:
+.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"
+   user="username"
+   group="groupname"
+.fi
+
+.PP
+Examples:
+.nf
+   <deny send_destination="org.freedesktop.Service" send_interface="org.freedesktop.System" send_member="Reboot"/>
+   <deny send_destination="org.freedesktop.System"/>
+   <deny receive_sender="org.freedesktop.System"/>
+   <deny user="john"/>
+   <deny group="enemies"/>
+.fi
+
+.PP
+The <deny> 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).
+.PP
+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.
+.PP
+The other send_* and receive_* attributes are purely textual/by-value
+matches against the given field in the message header.
+.PP
+"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).
+.PP
+For <allow>, 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 <deny>, eavesdrop="true" indicates that the rule matches
+only when eavesdropping. eavesdrop="false" is the default for <deny>
+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).
+.PP
+The [send|receive]_requested_reply attribute works similarly to the eavesdrop
+attribute. It controls whether the <deny> or <allow> 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.
+
+.PP
+For <allow>, [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.
+
+.PP
+For <deny>, [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.
+
+.PP
+user and group denials mean that the given user or group may
+not connect to the message bus.
+
+.PP
+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.
+
+.PP
+It does not make sense to deny a user or group inside a <policy>
+for a user or group; user/group denials can only be inside
+context="default" or context="mandatory" policies.
+
+.PP
+A single <deny> 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. <deny send_interface="foo.bar" send_destination="foo.blah"/> would
+deny messages with the given interface AND the given bus name.
+To get an OR effect you specify multiple <deny> rules.
+
+.PP
+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.
+
+.PP
+Be careful with send_interface/receive_interface, because the
+interface field in messages is optional.  In particular, do NOT
+specify <deny send_interface="org.foo.Bar"/>!  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: <deny send_interface="org.foo.Bar" send_destination="org.foo.Service"/>
+
+.TP
+.I "<selinux>"
+
+.PP
+The <selinux> element contains settings related to Security Enhanced Linux.
+More details below.
+
+.TP
+.I "<associate>"
+
+.PP
+An <associate> element appears below an <selinux> element and
+creates a mapping. Right now only one kind of association is possible:
+.nf
+   <associate own="org.freedesktop.Foobar" context="foo_t"/>
+.fi
+
+.PP
+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.
+
+.PP
+Note, the context here is the target context when requesting a name,
+NOT the context of the connection owning the name.
+
+.PP
+There's currently no way to set a default for owning any name, if
+we add this syntax it will look like:
+.nf
+   <associate own="*" context="foo_t"/>
+.fi
+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.
+
+.PP
+If two <associate> elements specify the same name, the element
+appearing later in the configuration file will be used.
+
+.SH SELinux
+
+.PP
+See http://www.nsa.gov/selinux/ for full details on SELinux. Some useful excerpts:
+
+.IP "" 8
+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.
+
+.IP "" 8
+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.
+
+.IP "" 8
+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.
+
+.IP "" 8
+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.
+
+.PP
+D-Bus performs SELinux security checks in two places.
+
+.PP
+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".
+
+.PP
+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.
+
+.PP
+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".
+
+.PP
+The security context for a bus name is specified with the
+<associate> 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.
+
+.SH DEBUGGING
+
+.PP
+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.
+.PP
+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.
+.PP
+The simplest way to figure out what's happening on the bus is to run
+the \fIdbus-monitor\fP program, which comes with the D-Bus
+package. You can also send test messages with \fIdbus-send\fP. These
+programs have their own man pages.
+.PP
+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.
+.PP
+To run a separate test copy of the daemon, for example you might open a terminal
+and type:
+.nf
+  DBUS_VERBOSE=1 dbus-daemon --session --print-address
+.fi
+.PP
+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.
+.PP
+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.)
+.PP
+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.
+
+.SH AUTHOR
+See http://www.freedesktop.org/software/dbus/doc/AUTHORS
+
+.SH BUGS
+Please send bug reports to the D-Bus mailing list or bug tracker,
+see http://www.freedesktop.org/software/dbus/
diff --git a/doc/dbus-launch.1 b/doc/dbus-launch.1
new file mode 100644
index 00000000..0ea19495
--- /dev/null
+++ b/doc/dbus-launch.1
@@ -0,0 +1,183 @@
+.\" 
+.\" dbus-launch manual page.
+.\" Copyright (C) 2003 Red Hat, Inc.
+.\"
+.TH dbus-launch 1
+.SH NAME
+dbus-launch \- Utility to start a message bus from a shell script
+.SH SYNOPSIS
+.PP
+.B dbus-launch [\-\-version] [\-\-sh-syntax] [\-\-csh-syntax] [\-\-auto-syntax] [\-\-exit-with-session] [\-\-autolaunch=MACHINEID] [\-\-config-file=FILENAME] [PROGRAM] [ARGS...]
+
+.SH DESCRIPTION
+
+The \fIdbus-launch\fP command is used to start a session bus 
+instance of \fIdbus-daemon\fP from a shell script.
+It would normally be called from a user's login
+scripts. Unlike the daemon itself, \fIdbus-launch\fP exits, so
+backticks or the $() construct can be used to read information from
+\fIdbus-launch\fP.
+
+With no arguments, \fIdbus-launch\fP will launch a session bus
+instance and print the address and pid of that instance to standard
+output.
+
+You may specify a program to be run; in this case, \fIdbus-launch\fP
+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.
+
+If you launch a program, \fIdbus-launch\fP will not print the
+information about the new bus to standard output.
+
+When \fIdbus-launch\fP 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 \fIdbus-launch\fP to emit shell code
+to set up the environment.
+
+With the \-\-auto-syntax option, \fIdbus-launch\fP 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.
+
+.PP
+See http://www.freedesktop.org/software/dbus/ for more information
+about D-Bus. See also the man page for \fIdbus-daemon\fP.
+
+.PP
+Here is an example of how to use \fIdbus-launch\fP with an 
+sh-compatible shell to start the per-session bus daemon:
+.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
+
+.fi
+You might run something like that in your login scripts.
+
+.PP
+Another way to use \fIdbus-launch\fP is to run your main session
+program, like so:
+.nf
+
+dbus-launch gnome-session
+
+.fi
+The above would likely be appropriate for ~/.xsession or ~/.Xclients.
+
+.SH AUTOMATIC LAUNCHING
+
+.PP
+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/
+
+.PP
+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.
+
+.PP
+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.
+
+.PP
+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.
+
+.PP
+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.)
+
+.PP
+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.
+
+.SH OPTIONS
+The following options are supported:
+.TP
+.I "--auto-syntax"
+Choose \-\-csh-syntax or \-\-sh-syntax based on the SHELL environment variable.
+
+.I "--binary-syntax"
+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.
+
+.TP
+.I "--close-stderr"
+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.
+
+.TP
+.I "--config-file=FILENAME"
+Pass \-\-config-file=FILENAME to the bus daemon, instead of passing it 
+the \-\-session argument. See the man page for dbus-daemon
+
+.TP
+.I "--csh-syntax"
+Emit csh compatible code to set up environment variables.
+
+.TP
+.I "--exit-with-session"
+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.
+
+.TP
+.I "--autolaunch=MACHINEID"
+This option implies that \fIdbus-launch\fP 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.
+
+.TP
+.I "--sh-syntax"
+Emit Bourne-shell compatible code to set up environment variables.
+
+.TP
+.I "--version"
+Print the version of dbus-launch
+
+.SH AUTHOR
+See http://www.freedesktop.org/software/dbus/doc/AUTHORS
+
+.SH BUGS
+Please send bug reports to the D-Bus mailing list or bug tracker,
+see http://www.freedesktop.org/software/dbus/
diff --git a/doc/dbus-monitor.1 b/doc/dbus-monitor.1
new file mode 100644
index 00000000..c24c14d9
--- /dev/null
+++ b/doc/dbus-monitor.1
@@ -0,0 +1,78 @@
+.\" 
+.\" dbus-monitor manual page.
+.\" Copyright (C) 2003 Red Hat, Inc.
+.\"
+.TH dbus-monitor 1
+.SH NAME
+dbus-monitor \- debug probe to print message bus messages
+.SH SYNOPSIS
+.PP
+.B dbus-monitor
+[\-\-system | \-\-session | \-\-address ADDRESS] [\-\-profile | \-\-monitor]
+[watch expressions]
+
+.SH DESCRIPTION
+
+The \fIdbus-monitor\fP command is used to monitor messages going
+through a D-Bus message bus.  See
+http://www.freedesktop.org/software/dbus/ for more information about
+the big picture.
+
+.PP
+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 \fIdbus-monitor\fP to
+monitor the system or session buses respectively.  If neither is
+specified, \fIdbus-monitor\fP monitors the session bus.
+
+.PP
+\fIdbus-monitor\fP 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,
+\fIdbus-monitor\fP uses the monitoring output format.
+
+.PP
+In order to get \fIdbus-monitor\fP 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 \fIdbus_bus_add_match\fP function.
+
+.PP 
+The message bus configuration may keep \fIdbus-monitor\fP from seeing
+all messages, especially if you run the monitor as a non-root user.
+
+.SH OPTIONS
+.TP
+.I "--system"
+Monitor the system message bus.
+.TP
+.I "--session"
+Monitor the session message bus.  (This is the default.)
+.TP
+.I "--address ADDRESS"
+Monitor an arbitrary message bus given at ADDRESS.
+.TP
+.I "--profile"
+Use the profiling output format.
+.TP
+.I "--monitor"
+Use the monitoring output format.  (This is the default.)
+
+.SH EXAMPLE
+Here is an example of using dbus-monitor to watch for the gnome typing
+monitor to say things
+.nf
+
+  dbus-monitor "type='signal',sender='org.gnome.TypingMonitor',interface='org.gnome.TypingMonitor'"
+
+.fi
+
+.SH AUTHOR
+dbus-monitor was written by Philip Blundell.
+The profiling output mode was added by Olli Salli.
+
+.SH BUGS
+Please send bug reports to the D-Bus mailing list or bug tracker,
+see http://www.freedesktop.org/software/dbus/
diff --git a/doc/dbus-send.1 b/doc/dbus-send.1
new file mode 100644
index 00000000..4878c3d9
--- /dev/null
+++ b/doc/dbus-send.1
@@ -0,0 +1,95 @@
+.\" 
+.\" dbus-send manual page.
+.\" Copyright (C) 2003 Red Hat, Inc.
+.\"
+.TH dbus-send 1
+.SH NAME
+dbus-send \- Send a message to a message bus
+.SH SYNOPSIS
+.PP
+.B dbus-send
+[\-\-system | \-\-session] [\-\-dest=NAME] [\-\-print-reply]
+[\-\-type=TYPE] <destination object path> <message name> [contents ...]
+
+.SH DESCRIPTION
+
+The \fIdbus-send\fP command is used to send a message to a D-Bus message
+bus. See http://www.freedesktop.org/software/dbus/ for more 
+information about the big picture.
+
+.PP
+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 \fIdbus-send\fP to send
+messages to the system or session buses respectively.  If neither is
+specified, \fIdbus-send\fP sends to the session bus.
+
+.PP 
+Nearly all uses of \fIdbus-send\fP 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.
+
+.PP
+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.
+
+.nf
+<contents>   ::= <item> | <container> [ <item> | <container>...]
+<item>       ::= <type>:<value>
+<container>  ::= <array> | <dict> | <variant>
+<array>      ::= array:<type>:<value>[,<value>...] 
+<dict>       ::= dict:<type>:<type>:<key>,<value>[,<key>,<value>...]
+<variant>    ::= variant:<type>:<value>
+<type>       ::= string | int16 | uint 16 | int32 | uint32 | int64 | uint64 | double | byte | boolean | objpath
+.fi
+
+D-Bus supports more types than these, but \fIdbus-send\fP currently
+does not.  Also, \fIdbus-send\fP does not permit empty containers
+or nested containers (e.g. arrays of variants).
+
+.PP
+Here is an example invocation:
+.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 
+
+.fi
+
+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.
+
+.SH OPTIONS
+The following options are supported:
+.TP
+.I "--dest=NAME"
+Specify the name of the connection to receive the message.
+.TP
+.I "--print-reply"
+Block for a reply to the message sent, and print any reply received.
+.TP
+.I "--system"
+Send to the system message bus.
+.TP
+.I "--session"
+Send to the session message bus.  (This is the default.)
+.TP
+.I "--type=TYPE"
+Specify "method_call" or "signal" (defaults to "signal").
+
+.SH AUTHOR
+dbus-send was written by Philip Blundell.
+
+.SH BUGS
+Please send bug reports to the D-Bus mailing list or bug tracker,
+see http://www.freedesktop.org/software/dbus/
diff --git a/doc/dbus-uuidgen.1 b/doc/dbus-uuidgen.1
new file mode 100644
index 00000000..480fd18f
--- /dev/null
+++ b/doc/dbus-uuidgen.1
@@ -0,0 +1,89 @@
+.\" 
+.\" dbus-uuidgen manual page.
+.\" Copyright (C) 2006 Red Hat, Inc.
+.\"
+.TH dbus-uuidgen 1
+.SH NAME
+dbus-uuidgen \- Utility to generate UUIDs
+.SH SYNOPSIS
+.PP
+.B dbus-uuidgen [\-\-version] [\-\-ensure[=FILENAME]] [\-\-get[=FILENAME]]
+
+.SH DESCRIPTION
+
+The \fIdbus-uuidgen\fP command generates or reads a universally unique ID.
+
+.PP
+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").
+
+.PP
+See http://www.freedesktop.org/software/dbus/ for more information
+about D-Bus.
+
+.PP
+The primary usage of \fIdbus-uuidgen\fP is to run in the post-install
+script of a D-Bus package like this:
+.nf
+  dbus-uuidgen --ensure
+.fi
+
+.PP
+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.
+
+.PP
+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.
+
+.PP
+If you run \fIdbus-uuidgen\fP with no options it just prints a new uuid made
+up out of thin air.
+
+.PP
+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.
+
+.PP
+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.
+
+.PP
+The UUID should be different on two different virtual machines,
+because there are two different kernels.
+
+.SH OPTIONS
+The following options are supported:
+.TP
+.I "--get[=FILENAME]"
+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.
+
+.TP
+.I "--ensure[=FILENAME]"
+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.
+
+.TP
+.I "--version"
+Print the version of dbus-uuidgen
+
+.SH AUTHOR
+See http://www.freedesktop.org/software/dbus/doc/AUTHORS
+
+.SH BUGS
+Please send bug reports to the D-Bus mailing list or bug tracker,
+see http://www.freedesktop.org/software/dbus/