> However, when I actually started to try and use TurboVNC, I could start
> vncserver, but when I tried to connect from a client, it would not finish
> connecting and the log file indicated the connection aborted due to some
> illegal commands. I suspect that actually might be a problem with the x86
> emulator running the Alpine Linux (as it is known to not be able to yet run
> all Linux programs)
If the emulator doesn’t have full support for various x86 SIMD instruction
sets, then that could explain it. Try setting JSIMD_FORCENONE=1 in the
environment to turn off SIMD acceleration in libjpeg-turbo, but understand that
that will reduce the performance of the TurboVNC Server dramatically.
> 1) connect remotely to TurboVNC vncserver with any VNC viewer (i.e. not just
> TurboVNC vncviewer)? I want to be able to do so since I’m aiming to use
> TurboVNC to allow me to see Linux 3D graphics on my iPad Alpine LInux
> emulator which the server is on does not have 3D graphics capabilities itself
> (so VirtualGL won’t helP) and the viewer client is a separate app on my iPAD
> that is not a Linux device (i.e. I couldn’t install TurboVNC vncviewer on it)
Yes. Refer to the TurboVNC User’s Guide for compatibility notes. Generally, any
VNC viewer will work, but only VNC viewers that support the TightVNC decoder
with TurboVNC’s optimizations and the RFB flow control extensions will perform
optimally in all cases. Currently, that includes only the TurboVNC and TigerVNC
Viewers.
> 2) view 3D graphics (eg openGL graphics) originating from the linux TurboVNC
> vncserver headless host given as I mentioned above that the headless host
> does not have any means to render 3D graphics (i.e. no ability to connect
> directly from the LInux server to the iPAD’s graphic system) and no link from
> the iPad’s separate non-Linux VNC viewer to render 3D graphics from the
> viewer itself. My understanding is that the TurboVNC program is the only VNC
> program that can software render 3D graphics coming from the VNC server and
> convert such graphics to a 2D image to then send and be displayed on the VNC
> non-linux, non 3D graphics viewer. If I am mistaken in this ability of
> TurboVNC’s then, I will not ask you further for assistance in trying to get
> this to work for my needs and the needs of the iSH Linux x86 emulator
> community (it may still be useful for the larger Alpine LInux community
> though as you helped me show that it at least can be built on that
> distribution).
“view 3D graphics (eg openGL graphics) originating from the linux TurboVNC
vncserver headless host” is awkward terminology, so I don’t quite understand
your meaning there. If you mean that you want to remotely display the output of
the TurboVNC host’s graphics card/GPU, then no, TurboVNC cannot do that.
TurboVNC creates one or more virtual X servers on demand, and those virtual X
servers are not connected to the host’s graphics hardware (VirtualGL is used to
establish that connection for the purpose of enabling GPU acceleration for
OpenGL.) If software-rendered OpenGL is all you need, however, then the
TurboVNC Server does support that. It is not the only VNC server that supports
that, however. TigerVNC does too, although their server is generally a lot
harder to build.
> I appreciate your further thoughts and time; I’ve learned a lot more about
> Linux, cmake, make and X from trying to build this on my machine.
> Sincerely,
>
>> On Friday, May 21, 2021 at 3:15:26 PM UTC-7 DRC wrote:
>> I just noticed that, earlier, you tried to do:
>>
>> make CFLAGS=-D_GNU_SOURCE
>>
>> That won't work with CMake-generated Makefiles, because CMake populates the
>> compiler flags in the Makefiles whenever it generates the build. Try
>> instead:
>>
>> cd {build-directory}
>> rm -rf CMake*
>> cmake {any-other-CMake-args-you-need} -DCMAKE_C_FLAGS="-D_GNU_SOURCE
>> -D__GLIBC__" {source-directory}
>> make
>>
>> NOTE: 'rm -rf CMake*' clears any cached build state. Doing that isn't
>> necessary with a fresh build directory, nor is it necessary when rebuilding.
>> I only suggested it above in order to make 100% sure that the new compiler
>> flags are applied, because I can't remember how aggressively CMake caches
>> those.
>>
>> If that doesn't work, then I will repeat my advice to look at the X.org X
>> server package for Alpine and see what they did to make it build. X.org
>> also requires __GLIBC__ to be defined in features.h.
>>
>> To answer your question about __GLIBC__, there are other places within the
>> TurboVNC Server code that check for __GLIBC__ to be defined, so it's best to
>> define both __GLIBC__ and _GNU_SOURCE.
>>
>> DRC
>>
>>> On 5/21/21 3:44 PM, SugarRayLua wrote:
>>>
>>> Thanks, DRC.
>>>
>>> I do have glibc and its headers installed. I found features.h in the
>>> usr/include directory and printed its code as follows:
>>>
>>> iPad:/usr/include# cat ./features.h
>>> #ifndef _FEATURES_H
>>> #define _FEATURES_H
>>>
>>> #if defined(_ALL_SOURCE) && !defined(_GNU_SOURCE)
>>> #define _GNU_SOURCE 1
>>> #endif
>>>
>>> #if defined(_DEFAULT_SOURCE) && !defined(_BSD_SOURCE)
>>> #define _BSD_SOURCE 1
>>> #endif
>>>
>>> #if !defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE) \
>>> && !defined(_XOPEN_SOURCE) && !defined(_GNU_SOURCE) \
>>> && !defined(_BSD_SOURCE) && !defined(__STRICT_ANSI__)
>>> #define _BSD_SOURCE 1
>>> #define _XOPEN_SOURCE 700
>>> #endif
>>>
>>> #if __STDC_VERSION__ >= 199901L
>>> #define __restrict restrict
>>> #elif !defined(__GNUC__)
>>> #define __restrict
>>> #endif
>>>
>>> #if __STDC_VERSION__ >= 199901L || defined(__cplusplus)
>>> #define __inline inline
>>> #elif !defined(__GNUC__)
>>> #define __inline
>>> #endif
>>>
>>> #if __STDC_VERSION__ >= 201112L
>>> #elif defined(__GNUC__)
>>> #define _Noreturn __attribute__((__noreturn__))
>>> #else
>>> #define _Noreturn
>>> #endif
>>>
>>> #endif
>>>
>>> Sorry about my continued linux knowledge limit but is defining _GNU_SOURCE
>>> 1 the same as defining _GLIBC_ as you suggested? If so, then will let the
>>> Alpine Linux support know what you’ve said and wait to see if they can
>>> offer any further suggestions.
>>>
>>> If my features.h file doesn’t define _GLIBC_ could I modify the file myself
>>> to define it? I realize that it is a header file and part of an important
>>> library of core code so may not be a good idea. However, I’m not running
>>> any critical files on my linux install, and if the Alpine Linux support
>>> thought it might work by adding a definition to that file, I’d be willing
>>> to try it.
>>>
>>> What do you think?
>>>
>>> Sincerely,
>>> On Friday, May 21, 2021 at 9:42:10 AM UTC-7 DRC wrote:
>>>> I assume you also have the glibc development headers/library installed?
>>>> If so, then /usr/include/features.h should exist, and that header should
>>>> define __GLIBC__. If it doesn't, then that's also a distribution-specific
>>>> issue.
>>>>
>>>> If you have the glibc development headers/library installed and the build
>>>> is still failing, then I'm clueless. The TurboVNC build system detects
>>>> glibc in exactly the same way that the (autotools-based) X.org build
>>>> system does. Thus, the X.org Alpine package may have faced similar
>>>> difficulties, and it may be instructive to look at that package and see
>>>> how they worked around them.
>>>>
>>>> glibc is a documented requirement of the TurboVNC Server on Linux. Even
>>>> if we were able to work around this specific compatibility issue with
>>>> musl, there are many others that would pop up.
>>>>
>>>> DRC
>>>>
>>>> On 5/20/21 4:13 PM, SugarRayLua wrote:
>>>>> Thanks, DRC.
>>>>>
>>>>> If I am understanding your instructions correctly, I do not think
>>>>> _GNU_SOURCE is defined on the command line that builds access.c:
>>>>>
>>>>> “
>>>>> Building C object
>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o
>>>>> cd /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os && /usr/bin/cc
>>>>> -DCLIENTIDS -DCOMPOSITE -DDAMAGE -DDPMSExtension -DGLXEXT -DHASXDMAUTH
>>>>> -DHAS_SHM -DHAVE_DIX_CONFIG_H -DHAVE_SHA1_IN_LIBSHA1 -DHAVE_XSHMFENCE
>>>>> -DIPv6 -DMITSHM -DMONOTONIC_CLOCK -DNVCONTROL -DPANORAMIX -DPRESENT
>>>>> -DRANDR -DRENDER -DRES -DSCREENSAVER -DSHAPE -DTCPCONN -DTURBOVNC
>>>>> -DUNIXCONN -DUSE_POLL -DXACE -DXCSECURITY -DXDMCP -DXF86BIGFONT -DXFIXES
>>>>> -DXINPUT -DXRECORD -DXTEST -DXV“
>>>>>
>>>>> Alpine Linux uses musl although I do have glib also installed.
>>>>>
>>>>> Is there any simple instructions you could offer for me to modify
>>>>> CMakeFile or my Make build to enable _GNU_SOUCE? I’ve tried make
>>>>> CFLAGS=-D_GNU_SOURCE but that doesn’t work. As a novice user, I don’t
>>>>> have the knowledge to do any other changes myself.
>>>>>
>>>>> I’ll write the Alpine Linux support also to see if there is anything they
>>>>> can suggest.
>>>>>
>>>>> Thanks for your continued efforts to help.
>>>>>
>>>>> Sincerely
>>>>> On Wednesday, May 19, 2021 at 7:26:04 AM UTC-7 DRC wrote:
>>>>>> I think this is also a distribution-specific issue. I verified that my
>>>>>> build is using the same code path in access.c that your build is using.
>>>>>> If sys/socket.h defines SO_PEERCRED, then access.c will try to use
>>>>>> 'struct ucred'. (NOTE: access.c is X.org code, not TurboVNC code.)
>>>>>> However, 'struct ucred' is apparently only defined if _GNU_SOURCE is
>>>>>> defined, so the first thing I would do is 'make VERBOSE=1' and verify
>>>>>> whether _GNU_SOURCE is defined on the command line that builds access.c.
>>>>>> If it isn't, then it's probably because this build system check failed:
>>>>>> https://github.com/TurboVNC/turbovnc/blob/main/unix/Xvnc/CMakeLists.txt#L4-L9,
>>>>>> which would happen if features.h doesn't define __GLIBC__ on your
>>>>>> system. It could also be that, for whatever reason, your system doesn't
>>>>>> define 'struct ucred'.
>>>>>>
>>>>>> On 5/15/21 9:36 PM, SugarRayLua wrote:
>>>>>>> Thanks again for your continued help.
>>>>>>>
>>>>>>> If I am understanding you correctly, no, I did not make the build with
>>>>>>> adding the switch “TVNC_SYSTEMX11=1”) if that was what your were asking
>>>>>>> (i.e. just did “make”)
>>>>>>>
>>>>>>> Here is the relevant debug output again but with make VERBOSE=1:
>>>>>>>
>>>>>>> [ 84%] Built target sync
>>>>>>> make -f unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make
>>>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/depend
>>>>>>> make[2]: Entering directory '/root/turbovnc-2.2.6'
>>>>>>> cd /root/turbovnc-2.2.6 && /usr/bin/cmake -E cmake_depends "Unix
>>>>>>> Makefiles" /root/turbovnc-2.2.6
>>>>>>> /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os /root/turbovnc-2.2.6
>>>>>>> /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os
>>>>>>> /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/DependInfo.cmake
>>>>>>> --color=
>>>>>>> make[2]: Leaving directory '/root/turbovnc-2.2.6'
>>>>>>> make -f unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make
>>>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build
>>>>>>> make[2]: Entering directory '/root/turbovnc-2.2.6'
>>>>>>> [ 84%] Building C object
>>>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o
>>>>>>> cd /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os && /usr/bin/cc
>>>>>>> -DCLIENTIDS -DCOMPOSITE -DDAMAGE -DDPMSExtension -DGLXEXT -DHASXDMAUTH
>>>>>>> -DHAS_SHM -DHAVE_DIX_CONFIG_H -DHAVE_SHA1_IN_LIBSHA1 -DHAVE_XSHMFENCE
>>>>>>> -DIPv6 -DMITSHM -DMONOTONIC_CLOCK -DNVCONTROL -DPANORAMIX -DPRESENT
>>>>>>> -DRANDR -DRENDER -DRES -DSCREENSAVER -DSHAPE -DTCPCONN -DTURBOVNC
>>>>>>> -DUNIXCONN -DUSE_POLL -DXACE -DXCSECURITY -DXDMCP -DXF86BIGFONT
>>>>>>> -DXFIXES -DXINPUT -DXRECORD -DXTEST -DXV
>>>>>>> -I/root/turbovnc-2.2.6/unix/include
>>>>>>> -I/root/turbovnc-2.2.6/unix/Xvnc/X_include
>>>>>>> -I/root/turbovnc-2.2.6/common/zlib
>>>>>>> -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/Xext
>>>>>>> -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/include
>>>>>>> -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/miext/damage
>>>>>>> -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/present
>>>>>>> -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/../../lib/pixman/pixman
>>>>>>> -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/../render
>>>>>>> -I/root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/../../../lib/libsha1
>>>>>>> -w -O3 -DNDEBUG -fno-strict-aliasing -o
>>>>>>> CMakeFiles/os.dir/access.c.o -c
>>>>>>> /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c
>>>>>>> /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c: In
>>>>>>> function 'GetLocalClientCreds':
>>>>>>> /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c:1178:18:
>>>>>>> error: storage size of 'peercred' isn't known
>>>>>>> 1178 | struct ucred peercred;
>>>>>>> | ^~~~~~~~
>>>>>>> make[2]: ***
>>>>>>> [unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make:96:
>>>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o] Error 1
>>>>>>> make[2]: Leaving directory '/root/turbovnc-2.2.6'
>>>>>>> make[1]: *** [CMakeFiles/Makefile2:2834:
>>>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/all] Error 2
>>>>>>> make[1]: Leaving directory '/root/turbovnc-2.2.6'
>>>>>>> make: *** [Makefile:150: all] Error 2
>>>>>>>
>>>>>>> On Saturday, May 15, 2021 at 5:05:14 PM UTC-7 DRC wrote:
>>>>>>>> Can you rerun with
>>>>>>>>
>>>>>>>> make VERBOSE=1
>>>>>>>>
>>>>>>>> ? I need to see which include directories are being passed to the
>>>>>>>> compiler, because it seems as if one of the in-tree X.org headers
>>>>>>>> isn’t being picked up (or are you using TVNC_SYSTEMX11?)
>>>>>>>>
>>>>>>>>> On May 15, 2021, at 4:46 PM, SugarRayLua <meaning...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Ok, thanks.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here is what I believe is the most verbose debugging of the relevant
>>>>>>>>> part of the make where the build stopped:
>>>>>>>>>
>>>>>>>>> Pruning file
>>>>>>>>> 'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/flags.make'.
>>>>>>>>> Finished prerequisites of target file
>>>>>>>>> 'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o'.
>>>>>>>>> Must remake target
>>>>>>>>> 'unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o'.
>>>>>>>>> Putting child 0x565bb320
>>>>>>>>> (unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o) PID 674
>>>>>>>>> on the chain.
>>>>>>>>> Live child 0x565bb320
>>>>>>>>> (unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o) PID 674
>>>>>>>>> [ 84%] Building C object
>>>>>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o
>>>>>>>>> Reaping winning child 0x565bb320 PID 674
>>>>>>>>> Live child 0x565bb320
>>>>>>>>> (unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o) PID 675
>>>>>>>>> /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c: In
>>>>>>>>> function 'GetLocalClientCreds':
>>>>>>>>> /root/turbovnc-2.2.6/unix/Xvnc/programs/Xserver/os/access.c:1178:18:
>>>>>>>>> error: storage size of 'peercred' isn't known
>>>>>>>>> 1178 | struct ucred peercred;
>>>>>>>>> | ^~~~~~~~
>>>>>>>>> Reaping losing child 0x565bb320 PID 675
>>>>>>>>> make[2]: ***
>>>>>>>>> [unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/build.make:96:
>>>>>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/access.c.o] Error 1
>>>>>>>>> Removing child 0x565bb320 PID 675 from chain.
>>>>>>>>> Reaping losing child 0x565d3d60 PID 673
>>>>>>>>> make[1]: *** [CMakeFiles/Makefile2:2834:
>>>>>>>>> unix/Xvnc/programs/Xserver/os/CMakeFiles/os.dir/all] Error 2
>>>>>>>>> Removing child 0x565d3d60 PID 673 from chain.
>>>>>>>>> Reaping losing child 0x565ac240 PID 522
>>>>>>>>> make: *** [Makefile:150: all] Error 2
>>>>>>>>> Removing child 0x565ac240 PID 522 from chain.“
>>>>>>>>>
>>>>>>>>> Please let me know if you need more information.
>>>>>>>>>
>>>>>>>>> Sincerely,
>>>>>>>>>
>>>>>>>>> On Saturday, May 15, 2021 at 5:04:43 AM UTC-7 DRC wrote:
>>>>>>>>>> Please post the full text of the error so I can see where it is
>>>>>>>>>> occurring. Build errors are never very meaningful without context.
>>>>>>>>>>
>>>>>>>>>>> On May 15, 2021, at 12:50 AM, SugarRayLua <meaning...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello, again, TurboVNC Community,
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I’m still trying to build TurboVNC for Alpine Linux x86 from
>>>>>>>>>>> downloaded tarball. I managed to get cmake to work successfully and
>>>>>>>>>>> got through 84% of the make build before I got an “in function
>>>>>>>>>>> ‘GetLocalClientCreds’ error = storage size of ‘peercred’ isn’t
>>>>>>>>>>> known error”. I’m still a Linux novice and searched the web for
>>>>>>>>>>> other users who encountered that error and most said that setting
>>>>>>>>>>> either the CFLAGS or CPPFLAGS variable to “-D_GNU_SOURCE” (e.g.
>>>>>>>>>>> make CFLAGS=-D_GNU_SOURCE) allowed the make build to compile.
>>>>>>>>>>> However, setting neither flag fixes the problem and allows the make
>>>>>>>>>>> build for me.
>>>>>>>>>>>
>>>>>>>>>>> Does anyone have any other suggestions?
>>>>>>>>>>>
>>>>>>>>>>> I appreciate any assistance anyone could offer.
>>>>>>>>>>>
>>>>>>>>>>> Thanks and have a good night.
>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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 on the web visit
>>>>>>>>>>> https://groups.google.com/d/msgid/turbovnc-users/797b6ea1-993a-4e5e-a718-d6f47b94379dn%40googlegroups.com.
>>>>>>>>> --
>>>>>>>>> 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 on the web visit
>>>>>>>>> https://groups.google.com/d/msgid/turbovnc-users/ac661251-a0ef-4606-9ba2-a934692d4224n%40googlegroups.com.
>>>>>>> --
>>>>>>> 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 on the web visit
>>>>>>> https://groups.google.com/d/msgid/turbovnc-users/01f07e12-e2ea-40db-9a95-d5ba1c962addn%40googlegroups.com.
>>>>> --
>>>>> 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 on the web visit
>>>>> https://groups.google.com/d/msgid/turbovnc-users/08f243f1-58bf-4799-9df9-3d2d28f7c0d7n%40googlegroups.com.
>>> --
>>> 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 on the web visit
>>> https://groups.google.com/d/msgid/turbovnc-users/18137fd8-d832-479d-960a-18fa2cb7a786n%40googlegroups.com.
>
> --
> 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-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/turbovnc-users/78975d38-d828-4605-b9db-e85f6b2c590en%40googlegroups.com.
--
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/turbovnc-users/946770A4-3768-49D6-921D-8D78DB4DFEF6%40virtualgl.org.
