The STATIC_DOCS, DTDS and all dist_ files except XMLTO_OUTPUT are in the
source tree. The XMLTO_OUTPUT and the man2html output are in the build
tree, and the BONUS_FILES already have $(srcdir) in their names.
Also change the rules that generate the dbus-docs directory so that if
they fail, they leave behind a temporary directory, rather than leaving
behind a dbus-docs directory that causes make to not run those rules
if re-run; and change the rules to scp files to the server, to put a
trailing "/" on paths, ensuring that the tarball won't be uploaded as
"www" if the www directory doesn't already exist.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=41047
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
diagram.png and diagram.svg are linked from dbus-tutorial.html but recent
changes to doc/Makefile.am mean that if htmldir is set with configure they are
installed such that the relative link from dbus-tutorial.html does not work.
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In a man page, "-" officially means a typographical (Unicode) hyphen,
which frequently breaks the ability to copy and paste code examples from
a man page. "\-" means the ASCII hyphen/minus character. See
<http://lintian.debian.org/tags/hyphen-used-as-minus-sign.html> for
more details.
Rather than trying to distinguish between hyphens, em-dashes and
hyphen/minus, I just replaced all ambiguous hyphens with \- by applying
this vim command repeatedly until it didn't find anything:
%s/\(^\|[^\\]\)-/\1\\-/g
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38284
Reviewed-by: Lennart Poettering <lennart@poettering.net>
Also rename HTML_FILES to XMLTO_OUTPUT, as a more self-describing name:
we have other HTML files which are not the output from xmlto.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=36156
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
It turns out that rsync --chmod means "pretend the source files had
already had this chmod operation applied to them", and not "chmod the
destination files" like you'd expect.
As a result, the -p (--perms) option is also needed, so that rsync will
"preserve" the modified permissions. Otherwise, the docs will not be
group-writeable as intended, and only the person who made the previous
upload will be able to upload them next time.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=36130
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
It's generated by configure.
Also use a more normal way to distribute man pages that are actually
source, and use man1_MANS rather than auto-detecting the section from
the man page, which is best-practice and slightly faster.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34292
Use ./configure --docdir=/foo (or --htmldir=/foo) to control where it
ends up. For instance, Debian could use:
--docdir=/usr/share/doc/dbus-1-doc --htmldir='${docdir}/html'
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=13495
Add DBUS_INVALID_NESTED_TOO_DEEPLY validity problem and a test that
should generate it.
Previously, we rejected deep nesting in the signature, but
variants allow dynamic message nesting, conditional only
on the depth of the message body.
The nesting limit is 64, which was also the limit in static
signatures. Empirically, dynamic nesting depth observed on my
Fedora 14 system doesn't exceed 2; 64 is really a huge limit.
https://bugs.freedesktop.org/show_bug.cgi?id=32321
Signed-Off-By: Colin Walters <walters@verbum.org>
Signed-off-by: Will Thompson <will.thompson@collabora.co.uk>
This uploads a doc tarball, and its contents, to the appropriate
location on dbus.freedesktop.org. It also uploads the DTDs to the
appropriate location on specifications.freedesktop.org.
I believe this uploads the same files as the old update-dbus-docs.sh
script did.
This will make integrating the building of HTML versions of these
manpages into the build system way easier, at the cost of keeping
manpages in a different directory to the source for the program they
describe. I think this is an acceptable trade-off.
This depends on GNU Make for the wildcard dependency on all the source
files in dbus/. If anyone objects very strongly to this, I'd welcome
suggestions of a more portable way to do this.
It was pointed out on the mailing list that it would be useful to know
that a given property has changed without conveying its value. Because
without this parameter a true_no_value property could change, however
there is no way for a client-side proxy to know _what_ property it was
(only that some property changed).
With the parameter, however, a client-side proxy can reliably discard
a cached property value.
Also rename the "true_no_value" to "invalidates" as the spec is now
using this language.
Also allow using the annotation in the enclosed interface name.
Also rename the annotation name so it uses Property in its name
instead of Properties. This is to be more consistent with the existing
org.freedesktop.DBus.Method.NoReply annotation which uses Method, not
Methods.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Some notes about this new signal
- The PropertiesChanged() signal is optional. An application can
convey support for this signal by either including or excluding it
from the returned introspection data much like apps not supporting
(or predating) the GetAll() method does not include GetAll() in the
introspection data.
- An object can use PropertiesChanged() but opt out of using it for
one or more properties by using the
org.freedesktop.DBus.Properties.EmitsChangedSignal
annotation on the properties in question
- Applications can start using this new signal without breaking
compatibility with clients relying on existing D-Bus API.
The intent of the patch is simply to standardize existing behavior
- EggDBus has a very similar signal called EggDBusPropertiesChanged()
(also on the org.freedesktop.DBus.Properties interface)
- NetworkManager has a PropertiesChanged() signal on each different
interface (e.g. not org.fd.D.P) that it implements
- GDBus, an implementation of the D-Bus protocol in GLib, already
implements this signal
Signed-off-by: David Zeuthen <davidz@redhat.com>
UpdateActivationEnvironment takes a a{ss}. This means only
valid UTF-8 can be used. Environment variables are normally
ascii, but in theory have no specific encoding to them. This
means that certain valid environment variables can't be sent
to the bus for updating its activation environment.
This commit just adds a note to the spec explaining this
restriction.
