I'm not sure why this is necessary. Setting $userDBus in turbovncserver.conf or passing -userdbus to vncserver (both of which set the TVNC_USERDBUS environment variable) already covers almost everything above. (DBUS_SESSION_BUS_ADDRESS is already set to /run/user/$(id -u)/bus when the TurboVNC session starts under your account.) The only thing not covered is running dbus-update-activation-environment, but in my testing, that doesn't seem to change the environment in the TurboVNC session. Can you give me a specific reproducible workflow that fails if $userDBus is set?
On Saturday, January 24, 2026 at 10:27:43 AM UTC-5 Nikita Chasnikov wrote: > Dear D.R., > > I've found that on many recent GNOME desktops some of the functionality > regarding e.g. online accounts was not working out of the box while being > in TurboVNC session. > That seems to be an issue of the org.freedesktop.secrets component. > > That was also causing some long initial gnome terminal start. > I've solved it by adding the next lines to the startup script: > > _USER_BUS_SOCKET="/run/user/$(id -u)/bus" > if [ -S "$_USER_BUS_SOCKET" ]; then > # Only override if we aren't already pointing to it > if [ "$DBUS_SESSION_BUS_ADDRESS" != "unix:path=$_USER_BUS_SOCKET" ]; > then > export DBUS_SESSION_BUS_ADDRESS="unix:path=$_USER_BUS_SOCKET" > fi > export TVNC_USERDBUS=1 > if command -v dbus-update-activation-environment >/dev/null 2>&1; then > dbus-update-activation-environment --systemd --all > fi > fi > > Hope that it could be helpful. > This fixes e.g. initial long wait while gnome terminal is initiating. > > Kind regards, > Nick > > On Monday, December 22, 2025 at 4:22:31 PM UTC+1 DRC wrote: > >> The initial 3.3 beta2 release on Friday had a regression that caused >> VirtualGL to be enabled by default in all TurboVNC sessions. Since many >> users are already away from the office for the holidays and beta >> releases aren't canonical, I decided to yank the release and re-spin it >> with a fix, as well as incorporate a last-second fix for >> https://github.com/TurboVNC/turbovnc/issues/474. Apologies for the >> churn. Normally I would not do things that way, but I was already away >> from the office for the holidays as well. This was the most expedient >> way to solve the problem without access to my lab equipment. Otherwise, >> I would have had to delay the release cycle by another week. >> >> If anyone downloaded the initial 3.3 beta2 release before it was pulled, >> you can work around the aforementioned regression by setting >> >> $vglrun = ""; >> >> in turbovncserver.conf. (Not a big deal, but it affected the ability of >> most users to test the software.) The old packages with the bug had a >> build number of 20251219. The new packages with the fix have a build >> number of 20251222. >> >> Binaries, source tarball, and change log are here: >> https://github.com/TurboVNC/turbovnc/releases/tag/3.3beta2 >> >> -- You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/81382558-5131-4fbc-9af8-025f5b6e7320n%40googlegroups.com.
