On Thu Sep 10, 2026 at 1:36 PM CEST, Marco van Hulten wrote:
> On Thu Sep 10, 2026 at 1:15 PM CEST, Rafael Sadowski wrote:
>> On Thu Sep 10, 2026 at 11:11:00AM +0200, Marco van Hulten wrote:
>>> Hello,
>>>
>>> I am trying to run qutebrowser-3.7.0 on OpenBSD/arm64 -current (ThinkPad
>>> X13s). qutebrowser does not load any pages. I am on last night's
>>> snapshot (base and packages). Excluding config and loading a clean
>>> page:
>>>
>>> marco@neutrino:~$ qutebrowser --temp-basedir https://openbsd.org/
>>> 10:29:19 WARNING: No physical devices
>>> [70215:34683714048:0910/102919.852395:ERROR:../../../qtwebengine-everywhere-src-6.11.1/src/3rdparty/chromium/dbus/bus.cc:408]
>>> Failed to connect to the bus: Failed to connect to socket
>>> /var/run/dbus/system_bus_socket: No such file or directory
>>>
>>
>> Is you dbus setup working?
>
> I don't know. I have never tested this. I have this in my .xsession:
>
> eval $(dbus-launch --sh-syntax --exit-with-x11)
>
> and there is one dbus-launch and two dbus-daemon processes running.
The socket of the running dbus is /tmp/dbus-iGbdE0iyJT and
$DBUS_SESSION_BUS_ADDRESS is set to that. Nonetheless, qutebrowser
still complains about /var/run/dbus/system_bus_socket.
Even when I run
dbus-run-session -- qutebrowser
a new socket is created below /tmp/ whereas qutebrowser seems to insist
on using /var/run/dbus/system_bus_socket.
In the code there is exactly one place where system_bus_socket is
hard-coded: tests/end2end/fixtures/quteprocess.py:253 as an element in a
list of messages to be ignored. So it is not hard-coded in any
meaningful place and this suggests that the ERROR message is benign.
Marco
