We can no longer upload to specifications.freedesktop.org directly.
Instead, that area of the freedesktop.org web space is updated by
sending merge requests to the xdg/xdg-specs> project.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Now that we're installing the Doxygen documentation in a subdirectory,
the Devhelp index needs to reflect that.
Fixes: 522633b4 "cmake: install api docs in html subdir"
Fixes: f546ddd9 "meson: Install Doxygen docs as api/html/*.html"
Signed-off-by: Simon McVittie <smcv@debian.org>
This is useful when an asset manager wants to install a system
service while /usr/ is read-only (e.g.: portable services running
on a different namespaced image). Also recommend searching in /run/
following the now-standard pattern, for ephemeral services.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Tthis is useful when an asset manager wants to install a system
service while /usr/ is read-only (e.g.: portable
services running on a different namespaced image). Unlike other
directories, enforce strict naming and do not set up an inotify,
as the directories might not even exist until much later. Also
search in /run/ for ephemeral services that will disappear after
a reboot.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Readers of the message bus specification might be encountering Properties
for the first time, so for the basic properties in the o.fd.DBus
interface, link to the interface definition.
I'm not intending to add similar text for extension interfaces like
Containers.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, we arbitrarily divided o.fd.DBus into "messages"
(methods and signals), in one sect2, and Properties, in another sect2;
and for the only extended interface that is documented so far,
o.fd.DBus.Monitoring, we included its single method in the list of
o.fd.DBus methods.
This is putting too much weight on implementation details of how the
D-Bus protocol is implemented (with Properties being "less core" than
methods and signals), and not enough weight on how interfaces are
conceptually structured. It's more usual to group together all aspects
of an interface into one document or section, and the current arbitrary
separation is going to look more and more odd as we start documenting
more interfaces like Containers (dbus!449), Stats and Verbose.
Instead, repurpose the "Message Bus Messages" section to become the
documentation for the o.fd.DBus interface, and introduce a separate
section for each other interface that the message bus provides.
Each one contains a full list of methods, signals and properties (if any)
if it is specific to the message bus, or a cross-reference to a more
generic interface description if it is equally applicable to the message
bus and its clients.
Prompted by discussion on dbus!449.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This ensures that the Doxygen-built documentation has the same layout
in the installed files that it does in the build tree and on the
website. If we don't keep the same layout, then there is no value for
the `DBUS_APIDOC_LINK` in index.html that would be correct for both
the build tree and the installed tree. The build tree effectively has
a html subdirectory hard-coded, because that's how Doxygen lays out
its outputs.
This commit is the Meson equivalent of
commit 522633b4 "cmake: install api docs in html subdir" in the CMake
build system (dbus!473, dbus#519).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The newest release of the reference message bus that did not support
GetConnectionCredentials was 1.6.30, almost a decade ago.
It's entirely reasonable for new code to assume that
GetConnectionCredentials will succeed, and not implement a fallback.
Signed-off-by: Simon McVittie <smcv@collabora.com>
`<xref>` will typically be replaced by something like
"the section called “Foo”", so if we want to name a specific method
in running text, we need to use `<link>`.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The `AppArmor` feature flag is a case-sensitive string literal,
so consistently use its correct case-combination.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There's no need to make readers go looking for these in a larger section,
we can link directly to the individual interfaces.
Signed-off-by: Simon McVittie <smcv@collabora.com>
CMake has previously installed the api documentation in the api/
subdirectory, but api/html is required to correspond to the link
in the generated index file (index.html).
Fix#519
D-Feet is no longer maintained and its closest replacement, as mentioned
in the D-Feet page https://wiki.gnome.org/Apps/DFeet, is d-spy.
The project description doesn't need to be updated because d-spy
provides the same set of features that D-Feet had.
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
gitlab.fd.o/bustle/bustle points to the old archived project. The new
version has been rewritten in Rust and is now hosted at
gitlab.gnome.org/World/bustle
Signed-off-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
Make D-Bus implementations return a file descriptor
pinning the process as part of the credentials on
platforms that implement such concept, like Linux.
Pinning the process allows to defend against PID
reuse attacks, making authentication by
service/cgroup possible.
Signed-off-by: Luca Boccassi <bluca@debian.org>
The original code of 'ProgressNotification' had a wrong closing tag,
which should use '</signal>' instead of '</method>'
Signed-off-by: Yen-Chin, Lee <coldnew.tw@gmail.com>
The full license texts are not added because they were already
added in a previous commit.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
see #394
These files are licensed under the GPL only, without the AFL dual-license
of most of the dbus codebase.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Co-authored-by: Ralf Habacker <ralf.habacker@freenet.de>
The interoperable address is unix:path=/var/run/dbus/system_bus_socket.
However, in most (perhaps all) current Linux distributions, /var/run
is guaranteed to be a symbolic link to /run, and using the path in /run
has some advantages (particularly if automounters are used).
Implementations that intend to be interoperable are not required to
listen on exactly /var/run/dbus/system_bus_socket, as long as clients
that connect to that socket will work correctly. Similarly, clients
are not required to connect to exactly /var/run/dbus/system_bus_socket,
as long as the overall system (consisting of the client and the OSs
that it supports) ensures that it ends up connecting to the same
well-known system bus that is available at
/var/run/dbus/system_bus_socket.
Because of the Unix conventions for how software installs into a prefix,
building a D-Bus implementation with its default build-time
configuration options will not necessarily result in an interoperable
system bus. The system bus is normally shipped by OS distributors,
who should ensure that they have configured it in a way that is
interoperable.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/180
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it possible for projects to incorporate D-Bus as a CMake sub-project in a larger CMake project.
Before this PR, doing so would result in many errors.
This is because CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR would point to directories above the D-Bus project.
Using paths relative to the project directory, PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR, corrects for this.
The comment refers to the nul-padding of sockaddr_un member sun_path and
using an addrlen of sizeof(sockaddr_un). There is not much need to
document an old now "broken" behaviour.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Older versions of yelp-build like the one in Debian 11 do not allow
permuting arguments, so all options (in this case -o) must appear
before all positional parameters.
Signed-off-by: Simon McVittie <smcv@collabora.com>
