TurboVNC 3.3 beta2 has been re-released

[DRC]

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

[Nikita Chasnikov]

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

[DRC]

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?

[DRC]

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

--
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 turbovnc-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/81382558-5131-4fbc-9af8-025f5b6e7320n%40googlegroups.com.