From: "Marco van Hulten" Subject: Re: qutebrowser does not load pages To: "Rafael Sadowski" Cc: Date: Thu, 10 Sep 2026 15:09:36 +0200 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