dbus issues
https://gitlab.freedesktop.org/dbus/dbus/-/issues
2022-07-20T13:27:46Z
https://gitlab.freedesktop.org/dbus/dbus/-/issues/404
Increase minimum version of MSVC to one that we test in CI
2022-07-20T13:27:46Z
Simon McVittie
Increase minimum version of MSVC to one that we test in CI
We have a lot of things in our build that are being held back by "but what if MSVC doesn't support it?":
* making C99 `va_copy` a hard requirement (this would let us drop the probes for whether we need `__va_copy()` or an open-coded imp...
We have a lot of things in our build that are being held back by "but what if MSVC doesn't support it?":
* making C99 `va_copy` a hard requirement (this would let us drop the probes for whether we need `__va_copy()` or an open-coded implementation for MSVC)
* making C99 `static inline` a hard requirement (this would let us drop the `__inline` fallback)
* making C99 `snprintf()` a hard requirement (this would let us drop the `_snprintf` fallback in CMake)
* making C99 `strtoll()` and `strtoull()` a hard requirement (this would let us drop `tools/strto*ll.c` and related fallbacks)
* making a C99-compatible `<stdint.h>` a hard requirement (we can't necessarily redefine `dbus_int32_t` etc. for API reasons as discussed on !283, but we could at least add static assertions that say they are interchangeable, and potentially start using them internally)
MSVC 2013+ support quite a large subset of C99, and MSVC 2015+ have a much larger subset.
Now that @elmarco has added a CI job that runs on MSVC 2015, I'd like to start documenting that we require a C99 compiler for Unix, or at least the subset of C99 supported by MSVC 2015 for Windows. This would let us drop a lot of these workarounds, many of which we have trouble actually testing in practice (which probably means a lot of them are already broken and we just don't know it).
Alternatively, if there are reasons why we need to continue to support an older version of MSVC (like 2013?), then we should have CI that routinely tests that version, to verify that we haven't regressed.
Prior art: GLib is in the same situation as dbus (it's written in C, and wants to be portable to most Unixes, plus Windows and macOS), and the GLib developers publish a set of [toolchain requirements](https://gitlab.gnome.org/GNOME/glib/-/blob/main/docs/toolchain-requirements.md).
https://gitlab.freedesktop.org/dbus/dbus/-/issues/397
Deprecate / remove WinCE support
2022-07-13T19:09:39Z
Marc-André Lureau
Deprecate / remove WinCE support
Unless I am proved wrong, WinCE is nearing its EOL. Support will end sometime next year (https://docs.microsoft.com/en-us/lifecycle/products/windows-embedded-compact-2013)
What would be the process to actually remove WinCE support from ...
Unless I am proved wrong, WinCE is nearing its EOL. Support will end sometime next year (https://docs.microsoft.com/en-us/lifecycle/products/windows-embedded-compact-2013)
What would be the process to actually remove WinCE support from DBus?
(fwiw, meson doesn't support wince for !303)
https://gitlab.freedesktop.org/dbus/dbus/-/issues/210
Containers (#171): Last chance to change instance ID from 'o' to 'x'
2023-10-20T12:35:46Z
Bugzilla Migration User
Containers (#171): Last chance to change instance ID from 'o' to 'x'
One of the review comments on implementations of #171 that led to that issue stalling indefinitely was that some reviewers would prefer the container instance ID to be an opaque integer, probably `dbus_uint64_t` (`x`), rather than an obj...
One of the review comments on implementations of #171 that led to that issue stalling indefinitely was that some reviewers would prefer the container instance ID to be an opaque integer, probably `dbus_uint64_t` (`x`), rather than an object path.
See https://bugs.freedesktop.org/show_bug.cgi?id=106712 for the original discussion of this in a somewhat readable form (comments that were copied into this automatically-imported issue are not very readable).
We are constrained by some of the original implementation of Containers having been released in dbus 1.14.x. That version includes:
* `DBUS_HEADER_FIELD_CONTAINER_INSTANCE`, with value 10
* `dbus_bool_t dbus_message_set_container_instance(DBusMessage *, const char *)`
* `const char *dbus_message_get_container_instance (DBusMessage *)`
* The `const char *` in those C functions is documented as being an object path
So if we are going to convert the object path into an integer, we need to figure out a way to deprecate those and introduce an integer replacement.
We also should not make this change unless we have serious plans to introduce the ability to match signals against integers (#478).
@smcv is not particularly interested in this change, and so will not be working on it. If someone else wants this change, this is their chance to step forward to implement it.
## Deadline
If there is no substantial movement on this by the end of September 2023, then @smcv intends to reject this change and keep the container instance ID being an object path.
## Dependencies
@smcv will not accept this change unless someone (presumably someone who wanted this) steps forward to implement #478. It does not necessarily need to be finished before making this change.
/cc @dvdhrm @desrt
https://gitlab.freedesktop.org/dbus/dbus/-/issues/181
Consider dropping support for /var/run/console (--with-console-auth-dir)
2022-05-20T12:08:31Z
Bugzilla Migration User
Consider dropping support for /var/run/console (--with-console-auth-dir)
## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101629)](https://bugs.freedesktop.org/show_bug.cgi?id=101629)**
## Description
dbus-daemon implements the deprecated at_console feature (see a...
## Submitted by Simon McVittie
Assigned to **Simon McVittie**
**[Link to original bug (#101629)](https://bugs.freedesktop.org/show_bug.cgi?id=101629)**
## Description
dbus-daemon implements the deprecated at_console feature (see also Bug #39611) with several mechanisms. One of them is to stat the "tag file" /var/run/console/${username}, and if it exists, that is assumed to signify that ${username} is at the console. Those are the semantics that were implemented by pam_console and pam_foreground, both of which were later superseded by ConsoleKit, which was in turn superseded by systemd-logind (or occasionally ConsoleKit2) on Linux systems.
According to Bug #14053, some distributions patch ConsoleKit to create those tag files, but normally it does not. Judging by Bug #94591, ConsoleKit2 doesn't either.
For completeness, the other mechanisms we have for at_console are:
* for Linux with systemd or systemd-shim: check whether they are logged-in
on any seat using systemd-logind APIs
* for Solaris: there is a file that will be owned by the active console user
(assumed to be unique!)
I think we should consider removing the "tag files" handling.
Version: git master
### Depends on
* [Bug 101964](https://bugs.freedesktop.org/show_bug.cgi?id=101964)
https://gitlab.freedesktop.org/dbus/dbus/-/issues/168
make recommended system service naming mandatory
2018-10-15T13:43:32Z
Bugzilla Migration User
make recommended system service naming mandatory
## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99874)](https://bugs.freedesktop.org/show_bug.cgi?id=99874)**
## Description
dbus-daemon currently has the following unintended behaviour f...
## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99874)](https://bugs.freedesktop.org/show_bug.cgi?id=99874)**
## Description
dbus-daemon currently has the following unintended behaviour for system services whose filenames are not the canonical name (the well-known name + ".service"):
* Parse whichever service came first in readdir() order (might be the canonical name, or any other name[1]).
* Silently ignore any others.
* If the one that got parsed has a SystemdService set, use that for activation.
* If the one that got parsed does not have a SystemdService set, use the setuid helper for activation - but the setuid helper will load the file that has the canonical name instead (!), or if there is none, activation will fail.
When Bug #99825 lands, [1] will at least become a warning.
For the development branch, I think we should consider tightening this to: if the name is not canonical, just fail to load it. After Bug #99825, this would be easy to do.
Version: git master
### Depends on
* [Bug 99825](https://bugs.freedesktop.org/show_bug.cgi?id=99825)
https://gitlab.freedesktop.org/dbus/dbus/-/issues/167
consider warning when session services have the wrong name
2018-10-15T13:43:42Z
Bugzilla Migration User
consider warning when session services have the wrong name
## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99873)](https://bugs.freedesktop.org/show_bug.cgi?id=99873)**
## Description
Best practice for D-Bus session services is to define the serv...
## Submitted by Simon McVittie
Assigned to **D-Bus Maintainers**
**[Link to original bug (#99873)](https://bugs.freedesktop.org/show_bug.cgi?id=99873)**
## Description
Best practice for D-Bus session services is to define the service com.example.Foo in a file named com.example.Foo.service. This ensures that it is unambiguous which one is started: the one that is first in directory search order (this is not 100% reliable until one of the patches from Bug #99825 lands).
dbus-daemon could warn if a service is encountered that does not satisfy that constraint. However, this is currently wrong in a lot of software <https://lintian.debian.org/tags/dbus-session-service-wrong-name.html> so we should probably get some of those fixed first.
The cost of obeying that constraint is that if two software packages are deliberately providing implementations of the same well-known bus name, they will have file conflicts. However, this does not seem a whole lot worse than the current situation, where whichever one appears first in readdir() order is chosen, which I'm fairly sure is not what the software author intended.
Version: git master
### Depends on
* [Bug 99825](https://bugs.freedesktop.org/show_bug.cgi?id=99825)