Please respond to my question. If there is a legitimate issue in
TurboVNC, then I want to fix it, but I need to understand whether the
issue is legitimate or due to a misunderstanding of how $userDBus works.
DRC
On 1/24/26 10:50 AM, 'DRC' via TurboVNC User Discussion/Support wrote:
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
<https://groups.google.com/d/msgid/turbovnc-users/81382558-5131-4fbc-9af8-025f5b6e7320n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/f9da8ec9-23c2-4b00-a29d-04ae03827eb5%40virtualgl.org.
