Attachment 74696 Details for Bug 59805 – Use Docbook XML as the source for all man pages

[patch] Use Docbook XML as the source for all man pages

0005-Use-Docbook-XML-as-the-source-for-all-man-pages.patch (text/plain), 53.79 KB, created by Simon McVittie on 2013-02-12 16:04:45 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Simon McVittie

Created: 2013-02-12 16:04:45 UTC

Size: 53.79 KB

patch

obsolete

>From 6b5d40bae8ed6a15ddefb700195fc5bc29e4ced0 Mon Sep 17 00:00:00 2001
>From: Simon McVittie <simon.mcvittie@collabora.co.uk>
>Date: Tue, 12 Feb 2013 16:01:16 +0000
>Subject: [PATCH 5/5] Use Docbook XML as the source for all man pages
>
>This means we no longer need man2html, which is nice.
>---
> configure.ac               |   12 +-
> doc/.gitignore             |    3 +-
> doc/Makefile.am            |   72 ++---
> doc/dbus-cleanup-sockets.1 |   43 ---
> doc/dbus-daemon.1.in       |  766 --------------------------------------------
> doc/dbus-launch.1          |  211 ------------
> doc/dbus-monitor.1         |   78 -----
> doc/dbus-send.1            |  109 -------
> doc/dbus-uuidgen.1         |   89 -----
> 9 files changed, 41 insertions(+), 1342 deletions(-)
> delete mode 100644 doc/dbus-cleanup-sockets.1
> delete mode 100644 doc/dbus-daemon.1.in
> delete mode 100644 doc/dbus-launch.1
> delete mode 100644 doc/dbus-monitor.1
> delete mode 100644 doc/dbus-send.1
> delete mode 100644 doc/dbus-uuidgen.1
>
>diff --git a/configure.ac b/configure.ac
>index 1c8b705..37e33dc 100644
>--- a/configure.ac
>+++ b/configure.ac
>@@ -1488,13 +1488,8 @@ fi
> AM_CONDITIONAL(DBUS_XML_DOCS_ENABLED, test x$enable_xml_docs = xyes)
> AC_MSG_RESULT($enable_xml_docs)
> 
>-AC_PATH_PROG([MAN2HTML], [man2html])
>-AC_ARG_VAR([MAN2HTML], [Path to man2html (optional)])
>-AM_CONDITIONAL(DBUS_HAVE_MAN2HTML, test x$MAN2HTML != x)
>-
> AM_CONDITIONAL(DBUS_CAN_UPLOAD_DOCS,
>-    test x$enable_doxygen_docs = xyes -a x$enable_xml_docs = xyes -a \
>-         x$MAN2HTML != x)
>+    [test x$enable_doxygen_docs = xyes && test x$enable_xml_docs = xyes])
> 
> #### Have to go $localstatedir->$prefix/var->/usr/local/var
> 
>@@ -1815,7 +1810,7 @@ tools/Makefile
> test/Makefile
> test/name-test/Makefile
> doc/Makefile
>-doc/dbus-daemon.1
>+doc/dbus-daemon.1.xml
> dbus-1.pc
> dbus-1-uninstalled.pc
> test/data/valid-config-files/debug-allow-all.conf
>@@ -1860,8 +1855,7 @@ echo "
> 	32-bit int:		  ${DBUS_INT32_TYPE}
> 	16-bit int:		  ${DBUS_INT16_TYPE}
>         Doxygen:                  ${DOXYGEN:-not found}
>-        xmlto:                    ${XMLTO:-not found}
>-        man2html:                 ${MAN2HTML:-not found}"
>+        xmlto:                    ${XMLTO:-not found}"
> 
> echo "
>         Rebuilding generated files: ${USE_MAINTAINER_MODE}
>diff --git a/doc/.gitignore b/doc/.gitignore
>index 1afe014..d7c1236 100644
>--- a/doc/.gitignore
>+++ b/doc/.gitignore
>@@ -2,6 +2,7 @@
> .libs
> Makefile
> Makefile.in
>+*.1
> *.1.html
> *.lo
> *.la
>@@ -12,7 +13,7 @@ dbus-specification.html
> dbus-test-plan.html
> dbus-tutorial.html
> dbus-faq.html
>-dbus-daemon.1
>+dbus-daemon.1.xml
> dbus-docs
> dbus-docs.tar.gz
> doxygen.stamp
>diff --git a/doc/Makefile.am b/doc/Makefile.am
>index 96f7bc3..4906724 100644
>--- a/doc/Makefile.am
>+++ b/doc/Makefile.am
>@@ -1,20 +1,27 @@
> apidir = @htmldir@/api
> 
>-# automake normally assumes that man pages are generated files;
>-# these ones aren't, so we need the dist_ prefix to say that they're
>-# their own source code
>-dist_man1_MANS = \
>+MAN_XML_FILES = \
>+	dbus-daemon.1.xml \
>+	$(NULL)
>+
>+DIST_MAN_XML_FILES = \
>+	dbus-cleanup-sockets.1.xml \
>+	dbus-daemon.1.xml \
>+	dbus-launch.1.xml \
>+	dbus-monitor.1.xml \
>+	dbus-send.1.xml \
>+	dbus-uuidgen.1.xml \
>+	$(NULL)
>+
>+if DBUS_XML_DOCS_ENABLED
>+man1_MANS = \
> 	dbus-cleanup-sockets.1 \
>+	dbus-daemon.1 \
> 	dbus-launch.1 \
> 	dbus-monitor.1 \
> 	dbus-send.1 \
> 	dbus-uuidgen.1
>-
>-# on the other hand, this one is generated
>-man1_MANS = \
>-	dbus-daemon.1
>-
>-MAN_IN_FILES = dbus-daemon.1.in
>+endif
> 
> MAN_HTML_FILES = \
> 	dbus-cleanup-sockets.1.html \
>@@ -32,6 +39,7 @@ dist_doc_DATA = system-activation.txt
> 
> # uploaded and distributed, but not installed
> STATIC_DOCS = \
>+	$(DIST_MAN_XML_FILES) \
> 	dbus-faq.xml \
> 	dbus-specification.xml \
> 	dbus-test-plan.xml \
>@@ -43,8 +51,7 @@ STATIC_DOCS = \
> EXTRA_DIST = \
> 	file-boilerplate.c \
> 	doxygen_to_devhelp.xsl \
>-	$(STATIC_DOCS) \
>-	$(MAN_IN_FILES)
>+	$(STATIC_DOCS)
> 
> html_DATA =
> 
>@@ -59,26 +66,22 @@ STATIC_HTML = \
> 
> dist_html_DATA += $(STATIC_HTML)
> 
>-XMLTO_OUTPUT=					\
>+XMLTO_HTML =					\
> 	dbus-faq.html				\
> 	dbus-specification.html			\
> 	dbus-test-plan.html			\
>-	dbus-tutorial.html
>+	dbus-tutorial.html			\
>+	$(MAN_HTML_FILES)			\
>+	$(NULL)
> 
> if DBUS_XML_DOCS_ENABLED
>-html_DATA += $(XMLTO_OUTPUT)
>+html_DATA += $(XMLTO_HTML)
> 
>-dbus-specification.html: dbus-specification.xml
>+%.html: %.xml
> 	$(XMLTO) html-nochunks $<
> 
>-dbus-test-plan.html: dbus-test-plan.xml
>-	$(XMLTO) html-nochunks $<
>-
>-dbus-tutorial.html: dbus-tutorial.xml
>-	$(XMLTO) html-nochunks $<
>-
>-dbus-faq.html: dbus-faq.xml
>-	$(XMLTO) html-nochunks $<
>+%.1: %.1.xml
>+	$(XMLTO) man $<
> endif
> 
> if DBUS_DOXYGEN_DOCS_ENABLED
>@@ -114,13 +117,6 @@ uninstall-local::
> 		rmdir $(DESTDIR)$(apidir)
> endif
> 
>-if DBUS_HAVE_MAN2HTML
>-html_DATA += $(MAN_HTML_FILES)
>-
>-%.1.html: %.1
>-	$(AM_V_GEN)( $(MAN2HTML) < $< > $@.tmp && mv $@.tmp $@ )
>-endif
>-
> if DBUS_CAN_UPLOAD_DOCS
> BONUS_FILES = \
> 	$(top_srcdir)/README \
>@@ -130,14 +126,15 @@ BONUS_FILES = \
> 	$(top_srcdir)/COPYING \
> 	$(top_srcdir)/ChangeLog
> 
>-dbus-docs: $(STATIC_DOCS) $(dist_doc_DATA) $(dist_html_DATA) $(MAN_HTML_FILES) $(BONUS_FILES) doxygen.stamp $(XMLTO_OUTPUT)
>+dbus-docs: $(STATIC_DOCS) $(MAN_XML_FILES) $(dist_doc_DATA) $(dist_html_DATA) $(MAN_HTML_FILES) $(BONUS_FILES) doxygen.stamp $(XMLTO_HTML)
> 	$(AM_V_at)rm -rf $@ $@.tmp
> 	$(AM_V_GEN)$(MKDIR_P) $@.tmp/api
> 	$(AM_V_at)cd $(srcdir) && cp $(STATIC_DOCS) @abs_builddir@/$@.tmp
> 	$(AM_V_at)cd $(srcdir) && cp $(dist_doc_DATA) @abs_builddir@/$@.tmp
> 	$(AM_V_at)cd $(srcdir) && cp $(STATIC_HTML) @abs_builddir@/$@.tmp
>-	$(AM_V_at)cp $(XMLTO_OUTPUT) @abs_builddir@/$@.tmp
>+	$(AM_V_at)cp $(XMLTO_HTML) @abs_builddir@/$@.tmp
> 	$(AM_V_at)cp $(MAN_HTML_FILES) @abs_builddir@/$@.tmp
>+	$(AM_V_at)cp $(MAN_XML_FILES) @abs_builddir@/$@.tmp
> 	$(AM_V_at)cp $(BONUS_FILES) @abs_builddir@/$@.tmp
> 	$(AM_V_at)cp -r api/html @abs_builddir@/$@.tmp/api
> 	$(AM_V_at)mv $@.tmp $@
>@@ -164,12 +161,15 @@ maintainer-upload-docs:
> 	@false
> endif
> 
>+CLEANFILES = \
>+	$(man1_MANS) \
>+	$(MAN_XML_FILES) \
>+	$(XMLTO_HTML) \
>+	$(NULL)
>+
> clean-local:
> 	rm -f $(html_DATA)
> 	rm -rf api
> 	rm -rf dbus-docs dbus-docs.tmp
> 	rm -f *.1.html
> 	rm -f doxygen.stamp
>-
>-maintainer-clean-local:
>-	rm -f $(XMLTO_OUTPUT)
>diff --git a/doc/dbus-cleanup-sockets.1 b/doc/dbus-cleanup-sockets.1
>deleted file mode 100644
>index a062d49..0000000
>--- a/doc/dbus-cleanup-sockets.1
>+++ /dev/null
>@@ -1,43 +0,0 @@
>-.\" 
>-.\" 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
>deleted file mode 100644
>index 53856e9..0000000
>--- a/doc/dbus-daemon.1.in
>+++ /dev/null
>@@ -1,766 +0,0 @@
>-.\"
>-.\" 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.
>-.TP
>-.I "\-\-nopidfile"
>-Don't write a PID file even if one is configured in the configuration
>-files.
>-
>-.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"
>-   own_prefix="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
>-<allow own_prefix="a.b"/> 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).
>-
>-.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
>deleted file mode 100644
>index e22a3be..0000000
>--- a/doc/dbus-launch.1
>+++ /dev/null
>@@ -1,211 +0,0 @@
>-.\" 
>-.\" 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 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.
>-
>-.PP
>-See http://www.freedesktop.org/software/dbus/ for more information
>-about D\-Bus. See also the man page for \fIdbus\-daemon\fP.
>-
>-.SH EXAMPLES
>-
>-Distributions running
>-.B dbus\-launch
>-as part of a standard X session should run
>-.B "dbus\-launch \-\-exit\-with\-session"
>-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:
>-
>-.RS
>-.B "dbus\-launch \-\-exit\-with\-session gnome\-session"
>-
>-.B "dbus\-launch \-\-exit\-with\-session openbox"
>-
>-.B "dbus\-launch \-\-exit\-with\-session ~/.xsession"
>-.RE
>-
>-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
>-.BR ~/.xsession ,
>-.B ~/.xinitrc
>-or
>-.BR ~/.Xclients .
>-
>-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:
>-
>-.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
>-.fi
>-Note that in this case, dbus-launch will exit, and dbus-daemon will not be
>-terminated automatically on logout.
>-
>-.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 NOTES
>-
>-If you run
>-.B "dbus\-launch myapp"
>-(with any other options), dbus\-daemon will
>-.I not
>-exit when
>-.B myapp
>-terminates: this is because
>-.B myapp
>-is assumed to be part of a larger session, rather than a session in its
>-own right.
>-
>-.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
>deleted file mode 100644
>index 6282b9e..0000000
>--- a/doc/dbus-monitor.1
>+++ /dev/null
>@@ -1,78 +0,0 @@
>-.\" 
>-.\" 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
>deleted file mode 100644
>index 131a60d..0000000
>--- a/doc/dbus-send.1
>+++ /dev/null
>@@ -1,109 +0,0 @@
>-.\" 
>-.\" 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
>-[\fB\-\-system\fP | \fB\-\-session\fP]
>-[\fB\-\-dest=\fINAME\fP]
>-[\fB\-\-print\-reply\fP[\fB=literal\fP]]
>-[\fB\-\-reply\-timeout=\fIMSEC\fP]
>-[\fB\-\-type=\fITYPE\fP]
>-\fIOBJECT_PATH\fP \fIINTERFACE\fB.\fIMEMBER\fP [\fICONTENTS\fP ...]
>-
>-.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 \fB\-\-system\fP and \fB\-\-session\fP options direct
>-\fBdbus\-send\fP to send messages to the system or session buses respectively.
>-If neither is specified, \fBdbus\-send\fP sends to the session bus.
>-
>-.PP 
>-Nearly all uses of \fBdbus\-send\fP must provide the \fB\-\-dest\fP argument
>-which is the name of a connection on the bus to send the message to. If
>-\fB\-\-dest\fP 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 \fBdbus\-send\fP currently
>-does not.  Also, \fBdbus\-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
>-.BI \-\-dest= NAME
>-Specify the name of the connection to receive the message.
>-.TP
>-.B "\-\-print\-reply"
>-Block for a reply to the message sent, and print any reply received
>-in a human-readable form.
>-.TP
>-.B "\-\-print\-reply=literal"
>-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.
>-.TP
>-.BI \-\-reply\-timeout= MSEC
>-Wait for a reply for up to \fIMSEC\fP milliseconds.
>-The default is implementation\(hydefined, typically 25 seconds.
>-.TP
>-.B "\-\-system"
>-Send to the system message bus.
>-.TP
>-.B "\-\-session"
>-Send to the session message bus.  (This is the default.)
>-.TP
>-.BI \-\-type= TYPE
>-Specify \fBmethod_call\fP or \fBsignal\fP (defaults to "\fBsignal\fP").
>-
>-.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
>deleted file mode 100644
>index 8ed8dd2..0000000
>--- a/doc/dbus-uuidgen.1
>+++ /dev/null
>@@ -1,89 +0,0 @@
>-.\" 
>-.\" 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/
>-- 
>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.