init_session_address() should raise a DBusError instead of doing _dbus_warn()
Submitted by Guy Harris
Assigned to D-Bus Maintainers
Description
Bug 6964 against Wireshark:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9694
is due to:
the person using the MacPorts version of Wireshark, which uses the MacPorts version of libpcap;
the MacPorts version of libpcap being a recent version, with support for capturing D-Bus traffic, and built with D-Bus support;
libpcap refusing to provide, in its API to get a list of devices on which it can capture, devices that can't be opened, and testing that by trying to open them;
calls to try to open the "dbus-system" device calling dbus_bus_get with DBUS_BUS_SYSTEM as the first argument;
the system perhaps not being configured properly;
Wireshark running its dumpcap program to get a list of devices on which it can capture (so that, if special privileges are needed to open devices on which to capture traffic, only dumpcap needs them, not Wireshark in its entirety), with the standard output and error from dumpcap piped to it, and assuming that only serious "I can't function" errors will show up on the standard error, in a standard format determined by dumpcap (failure to open a device is *not* such an error, under any circumstances, not even failure due to org.freedesktop.dbus-session.plist not having been loaded on OS X);
init_session_address() calling _dbus_warn() if _dbus_lookup_session_address() sets "supported" to TRUE and returns FALSE, causing exactly such an error to go to the standard error.
I didn't find any obvious way to suppress the error message, so I'm probably just going to forcibly disable D-Bus support on OS X in libpcap, pending some way to suppress it.
It's probably best if library routines not write to the standard output or error except in calls whose purpose is to write to the standard output or error. (And, yes, I know libpcap does that in some places; I'll fix that soon.)