I think that things like this deserve to go on a wiki somewhere... it
would make them much more accessible than mailing lists archives.

my 2p

Cheers
Antoine


On 10/01/2010 08:24 PM, Robert Goley wrote:
>   Wow, thanks for the detailed build instructions.  They are much
> appreciated.  I ended up doing builds for 64 OSX on Snow leopard.  I
> have the beginnings of a clickable app package for the viewer.  Works
> esentially the same as clicking on the vncviewer.exe in Windows.  I am
> going to make a script similar to makemacdmg so it can be added to the
> build process.  I have a zip of the compiled 64 bit version if anyone
> wants it for testing.  I will build the 32 bit version for Snow Leopard
> later and package it the same.  I will try to build under 7.5 on linux
> later and get you the specific errors I was getting too.
> 
> Robert
> 
> 
> On 10/01/2010 05:09 AM, DRC wrote:
>> The specific errors I see when trying to build with the Xorg 7.5 code on
>> RHEL 4 and 5 are as follows:
>>
>> configure.ac:468: error: possibly undefined macro: AC_MSG_ERROR
>>       If this token and others are legitimate, please use m4_pattern_allow.
>>       See the Autoconf documentation.
>> configure:463: error: possibly undefined macro: AM_DEFAULT_VERBOSITY
>> configure:2493: error: possibly undefined macro: AC_PROG_CC_C99
>> configure:4791: error: possibly undefined macro: AS_VERSION_COMPARE
>> configure:4793: error: possibly undefined macro: AC_MSG_WARN
>> autoreconf: /usr/bin/autoconf failed with exit status: 1
>>
>> Also AC-related, but I'm not sure if that's what you're seeing as well.
>>
>> As far as building with Windows, if all you need to build is just
>> VNCViewer, the most painless way to do it is to install a "legacy" MinGW
>> environment using the following installers:
>>
>> MinGW-5.1.6.exe (The MinGW project no longer has this available for
>> download, so e-mail me if you are unable to find it)
>> http://sourceforge.net/projects/mingw/files/MSYS/BaseSystem/msys-core/msys-1.0.11/MSYS-1.0.11.exe
>> http://sourceforge.net/projects/mingw/files/MSYS/Supplementary%20Tools/msysDTK-1.0.1/msysDTK-1.0.1.exe
>>
>> MinGW has a fancy new installer for the GCC 4.5 toolchain.
>> Unfortunately, however, that toolchain cannot be successfully used to
>> build TigerVNC, due to a problem described in this previous message:
>> http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00665.html
>>
>> I've verified that the problem still exists with the toolchain installed
>> by the new MinGW installer.  :(
>>
>> The next step would be to download and install GnuTLS:
>> http://josefsson.org/gnutls4win/gnutls-2.10.1.exe
>>
>> and NASM:
>> http://www.nasm.us/pub/nasm/releasebuilds/2.09.02/win32/nasm-2.09.02-installer.exe
>> Install into c:\nasm
>>
>> Now, you should be able to open a new MSYS shell, check out (or update
>> to) the latest TigerVNC SVN trunk, then
>>
>>   cd tigervnc
>>   mkdir windows
>>   cd windows
>>   export CPATH=/c/Program\ Files/GnuTLS-2.10.1/include
>>   export LIBRARY_PATH=/c/Program\ Files/GnuTLS-2.10.1/lib
>>   sh ../configure NASM=/c/nasm/nasm.exe; make
>>
>>   To link statically with GNU TLS, instead do:
>>   sh ../configure GNUTLS_LDFLAGS='-Wl,-Bstatic -lgnutls -lgcrypt
>> -lgpg-error -ltasn1 -Wl,-Bdynamic -lws2_32' NASM=/c/nasm/nasm.exe; make
>>
>> Wait ... A very long time ...
>>
>> If everything goes well, you should now have a working binary under
>> tigervnc\windows\win\vncviewer\vncviewer.exe
>>
>> Issues:
>>
>> -- The resulting binary will not perform optimally, because the
>> libjpeg-turbo codec that TigerVNC uses for JPEG
>> compression/decompression requires GCC 4.1 or later or Visual C++ to
>> perform at its peak.  The 32-bit version of this codec, in particular,
>> will be noticeably slower when built with GCC 3.4.x
>>
>> -- Win64 support, or rather, lack thereof.  I have successfully built
>> TigerVNC for Win64, but it requires MinGW-w64, which isn't for the faint
>> of heart.  Also, there are currently no Win64 binaries for GnuTLS
>> (scuttlebutt on their forums seems to indicate that this is in the works.)
>>
>> -- MSYS autotools are ridiculously slow (the ones in Cygwin are even worse.)
>>
>> One other note:
>>
>> During this exercise, I also discovered that there aren't any Visual C++
>> static libraries for GnuTLS either.  <sigh>  That means that,
>> ultimately, building with Visual C++ via the proposed CMake build system
>> might require either building GnuTLS from source or using the DLL's.
>>
>> Fizzbin, anyone?
>>
>>
>> On 9/30/10 4:02 PM, Robert Goley wrote:
>>>  I was able to get it built correctly using the 7.4 release.  I have not
>>> had the chance to test it much but it built without any issues.  That
>>> was not the case when I tried it previously but that has been a
>>> while....   As for 7.5, the errors were AC related.  I got several
>>> warnings regarding quoting of TLS macros.  Otherwise, it was just
>>> configure errors with xorg.  It would build part of the dependencies and
>>> then bomb.  All is good with 7.4 using the -static option.  After I get
>>> this tested, I will move on to the Windows build....   :-(
>>>
>>>
>>> Robert
>>>
>>>
>>> On 09/30/2010 04:34 PM, DRC wrote:
>>>> The Xorg 7.5 code base is known not to work on older systems (RHEL 4 and
>>>> 5, in particular) due to an autotools incompatibility (even though the
>>>> configure.ac file in Xorg says it supports AC 2.57 and later, it uses
>>>> some macros that are only available on newer versions.)  However, it
>>>> should work on something as new as Lenny.  What is the specific build
>>>> error?  The Xorg 7.5 build changes are relatively new and untested, so
>>>> there may be a legitimate bug in the build-xorg system.
>>>>
>>>> On 9/30/10 12:49 PM, Robert Goley wrote:
>>>>>  Hmm...   That may be my problem.  I have been trying to build against
>>>>> 7.5 or the git repo.  I haven't tried 7.4 since before the TLS stuff was
>>>>> officially added.  I will try 7.4 again and post my results.  Noticed
>>>>> the typo in the last email.  I meant TigerVNC of course....  
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> On 09/30/2010 12:40 PM, DRC wrote:
>>>>>> Me too!  That is why I'm willing to work on the CMake system.  I haven't
>>>>>> yet been able to successfully build the Windows code myself, except for
>>>>>> just VNCViewer (which is painful because of all the MinGW dependencies.)
>>>>>>
>>>>>> As far as building on Lenny, I'm surprised that using build-xorg doesn't
>>>>>> work for you.  That method, when used with the Xorg 7.4 code base,
>>>>>> should be backward compatible all the way back to RHEL 4 and its
>>>>>> contemporaries (Ubuntu 6, etc.)
>>>>>>
>>>>>> On 9/30/10 8:46 AM, Robert Goley wrote:
>>>>>>>  I realize it would never completely replace autotools. I was just
>>>>>>> hoping for wrapper that would work a bit better.  I haven't had that
>>>>>>> much luck with compiling TigerVNC on Lenny yet.  The client stuff works
>>>>>>> fine but even compiling the whole Xorg tree for dependencies has not
>>>>>>> worked yet...  May have just been my frustration coming thru...  The
>>>>>>> Windows platform is next on my list and history tells me it never plays
>>>>>>> nice (MSVC or MinGW).  I really want to start working with TightVNC's
>>>>>>> TLS connections.  I applaud the work all the developers have done and
>>>>>>> look forward to when I can actually get to use it.
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> On 09/30/2010 01:25 AM, DRC wrote:
>>>>>>>> I didn't say that SCons didn't work great on Windows.  I just said that
>>>>>>>> it was my impression that CMake was more "Windows-friendly."  By that, 
>>>>>>>> I
>>>>>>>> mean it has full support for generating IDE projects and doesn't 
>>>>>>>> require
>>>>>>>> external dependencies like Python, etc.  I thought the link from the
>>>>>>>> SCons wiki was a pretty good summary of the trade-offs.
>>>>>>>>
>>>>>>>> Realistically, we're never going to be able to remove autotools from 
>>>>>>>> the
>>>>>>>> Unix/Linux build, because autotools is necessary to build Xorg.  Thus, 
>>>>>>>> I
>>>>>>>> don't see the point in trying to unify the build system across Windows
>>>>>>>> and Unix.  We already have that in our existing build system, which
>>>>>>>> requires using MinGW to build Windows binaries.  However, that system
>>>>>>>> ironically works a lot better on Linux than it does on an actual 
>>>>>>>> Windows
>>>>>>>> machine (see
>>>>>>>> http://www.mail-archive.com/tigervnc-devel@lists.sourceforge.net/msg00649.html),
>>>>>>>> and it requires using an unsupported patch to MinGW in order to build
>>>>>>>> WinVNC.
>>>>>>>>
>>>>>>>> I don't think that it will be that difficult to implement the CMake
>>>>>>>> system in TigerVNC, since I am implementing it in TurboVNC and
>>>>>>>> libjpeg-turbo first.  I'll be able to leverage a lot of that existing 
>>>>>>>> work.
>>>>>>>>
>>>>>>>> On 9/29/10 5:20 PM, Robert Goley wrote:
>>>>>>>>>   I am not sure on the visualization stuff or what you mean by it 
>>>>>>>>> exactly.  KDE moved to SCons initially and then to CMake because they 
>>>>>>>>> wanted custom changes and we not getting results as fast as they 
>>>>>>>>> liked.  
>>>>>>>>> I haven't seen anything that would require a custom change in SCons 
>>>>>>>>> myself.  It does work great on Windows though.  Not sure where you 
>>>>>>>>> got 
>>>>>>>>> the idea it didn't.  It was actually one of the first places I had to 
>>>>>>>>> use it.  It does require Python to be downloaded but Python is 
>>>>>>>>> available 
>>>>>>>>> and works fine on Windows.  It also has functionality to create MS 
>>>>>>>>> Studio Projects as well though this functionality may be limited in 
>>>>>>>>> some 
>>>>>>>>> areas.  I am more of a command line or automation type of guy for my 
>>>>>>>>> build systems but have used some of the MS project generation pieces. 
>>>>>>>>>  I 
>>>>>>>>> guess everyone has their preferences though.  Thanks for taking a 
>>>>>>>>> look 
>>>>>>>>> at it and responding so quickly.  My offer still stands on helping 
>>>>>>>>> with 
>>>>>>>>> a SCons based build system.  I can't offer the same help with the 
>>>>>>>>> CMake 
>>>>>>>>> system though.  I will be glad to see an improvement in the build 
>>>>>>>>> system 
>>>>>>>>> either way though.  I would love to be able to get it to compile on 
>>>>>>>>> Debian Lenny with one build command though I know Windows is your 
>>>>>>>>> focus.
>>>>>>>>>
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 09/29/2010 05:40 PM, DRC wrote:
>>>>>>>>>> I've looked at SCons cursorily.  The original reason why I started
>>>>>>>>>> looking at CMake was that I'm a visualization guy, and CMake has a 
>>>>>>>>>> lot
>>>>>>>>>> of traction in that community (that's where it came from originally.)
>>>>>>>>>> More generally, however, my (perhaps incorrect) impression is that 
>>>>>>>>>> there
>>>>>>>>>> seem to be more projects moving to CMake than SCons (including some
>>>>>>>>>> heavy hitters, like KDE), and it seems that CMake is more
>>>>>>>>>> Windows-friendly.  I like the idea of users being able to generate
>>>>>>>>>> Visual Studio project files and then use the Visual Studio IDE to
>>>>>>>>>> compile their project if they so desire.  Most Windows developers are
>>>>>>>>>> comfortable with this model.  Personally, I'm more of a command line
>>>>>>>>>> guy, so I like using Makefiles, but this gives us the option to 
>>>>>>>>>> support
>>>>>>>>>> both environments without supporting multiple build systems.  I don't
>>>>>>>>>> see any particularly compelling reason to move the Unix code off of
>>>>>>>>>> autotools, so really what we're looking for is what provides the best
>>>>>>>>>> solution for Windows native development.  CMake is a self-contained
>>>>>>>>>> executable, i.e. it doesn't require Python (which isn't available on
>>>>>>>>>> Windows systems), and thus it seems to be the most straightforward
>>>>>>>>>> solution.  The common view is that it's also faster, for the same 
>>>>>>>>>> reason.
>>>>>>>>>>
>>>>>>>>>> Interesting perspective here:
>>>>>>>>>> http://www.scons.org/wiki/SconsVsOtherBuildTools#head-3d0faf3f1d4d3b73f31eaa0ba97d4df18a474369
>>>>>>>>>>
>>>>>>>>>> On 9/29/10 3:11 PM, Robert Goley wrote:
>>>>>>>>>>>    I would be glad to see a better cross platform build system.  I 
>>>>>>>>>>> have
>>>>>>>>>>> done some work with CMake in the past and with SCons.  I found 
>>>>>>>>>>> Scons to
>>>>>>>>>>> be a better system overall.  One of the big selling points of it 
>>>>>>>>>>> for me
>>>>>>>>>>> was that it literally replaced the native systems make command and
>>>>>>>>>>> launched the compiler and linker directly instead of wrapping them.
>>>>>>>>>>> This seemed to allow for better concurrent object compiling with
>>>>>>>>>>> multiple processors/cores.  I saw my compile times cut in have 
>>>>>>>>>>> comparing
>>>>>>>>>>> it to GNU make's -j option with the same number of processors.
>>>>>>>>>>>
>>>>>>>>>>> Have you looked into SCons at all?  I know this is just my 2 cents 
>>>>>>>>>>> but I
>>>>>>>>>>> certainly would be willing to help with a SCons based build system.
>>>>>>>>>>> What are your thoughts?
>>>>>>>>>>>
>>>>>>>>>>> Robert
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09/29/2010 03:50 PM, DRC wrote:
>>>>>>>>>>>> I've been getting my hands dirty with CMake in recent weeks, and I 
>>>>>>>>>>>> now
>>>>>>>>>>>> firmly believe that's the way to go with respect to a Windows build
>>>>>>>>>>>> system for TigerVNC.  I don't propose replacing autotools (at 
>>>>>>>>>>>> least for
>>>>>>>>>>>> now), but CMake allows one to generate their own build system 
>>>>>>>>>>>> based on
>>>>>>>>>>>> NMake or Visual Studio projects or even MinGW, and it works with 
>>>>>>>>>>>> 64-bit.
>>>>>>>>>>>>    People can still use MinGW and autotools to build TigerVNC if 
>>>>>>>>>>>> they
>>>>>>>>>>>> want, but this gives native Windows developers a viable option for
>>>>>>>>>>>> working with our code that doesn't require compiler customizations.
>>>>>>>>>>>>
>>>>>>>>>>>> The intermediary step is for me to implement a CMake system for 
>>>>>>>>>>>> Windows
>>>>>>>>>>>> builds of libjpeg-turbo, and adding the system to TigerVNC should 
>>>>>>>>>>>> be
>>>>>>>>>>>> straightforward after this is done.
>>>>>>>>>>>>
>>>>>>>>>>>> Since this is currently unfunded work, I can't give a timeframe as 
>>>>>>>>>>>> to
>>>>>>>>>>>> when I might be able to complete it, but I believe that it needs 
>>>>>>>>>>>> to be
>>>>>>>>>>>> part of 1.1.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 9/16/10 4:15 AM, Adam Tkac wrote:
>>>>>>>>>>>>> On Thu, Sep 16, 2010 at 03:14:02AM -0500, DRC wrote:
>>>>>>>>>>>>>> Once I can successfully get a static build going on RHEL 4 
>>>>>>>>>>>>>> (still having
>>>>>>>>>>>>>> problems with the lack of gnutls_transport_set_global_errno), 
>>>>>>>>>>>>>> I'll look
>>>>>>>>>>>>>> into these issues.  libgcrypt and libgnutls are definitely not
>>>>>>>>>>>>>> cross-compatible, so the -static switch to build-xorg will 
>>>>>>>>>>>>>> probably have
>>>>>>>>>>>>>> to accommodate those libs as well as the others.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm hoping that the new Xorg 7.5 patches you just checked in will
>>>>>>>>>>>>>> eliminate the build issue I had previously that was preventing 
>>>>>>>>>>>>>> me from
>>>>>>>>>>>>>> using Xorg 7.5.  If so, I will generate a static Xvnc binary and 
>>>>>>>>>>>>>> look
>>>>>>>>>>>>>> into linking statically with gnutls.  I then want to try out the
>>>>>>>>>>>>>> security features to make sure they behave like I expect, and 
>>>>>>>>>>>>>> I'll be
>>>>>>>>>>>>>> cool with releasing the alpha at that point.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What is the situation with respect to doing Windows builds?  I 
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> never successfully managed to build WinVNC.  Did those patches 
>>>>>>>>>>>>>> ever make
>>>>>>>>>>>>>> it into a release of MinGW?
>>>>>>>>>>>>> My MinGW patch isn't accepted, yet. And I'm not sure if it will be
>>>>>>>>>>>>> accepted:
>>>>>>>>>>>>> https://sourceforge.net/mailarchive/message.php?msg_name=AANLkTikg0hAGpArLTqFSWn6IdSI5aNOwJk-3ZDl4rqrq%40mail.gmail.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm going to merge my "vcstudio_buildsys" branch to trunk so it 
>>>>>>>>>>>>> should
>>>>>>>>>>>>> be possible to build winvnc with both MSVC and MinGW.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, Adam
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/15/10 9:06 AM, Adam Tkac wrote:
>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> as you might have seen I performed build-xorg improvements
>>>>>>>>>>>>>>> and it is now possible to build Xvnc via those scripts. In my 
>>>>>>>>>>>>>>> opinion
>>>>>>>>>>>>>>> prebuilt Xvnc will be built with this script so it's good time 
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> discuss remaining issues.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Statically" linked Xvnc now contains references for following
>>>>>>>>>>>>>>> libraries:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> $ readelf -a ./Xvnc |grep NEEDE
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [libpam.so.0]
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [libgnutls.so.26]
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [libgcrypt.so.11]
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [libdl.so.2]
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [librt.so.1]
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [libm.so.6]
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [libc.so.6]
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [ld-linux-x86-64.so.2]
>>>>>>>>>>>>>>>    0x0000000000000001 (NEEDED)             Shared library: 
>>>>>>>>>>>>>>> [libpthread.so.0]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Everything except libgnutls.so.26 is present on old systems 
>>>>>>>>>>>>>>> (i.e. RHEL4&   friends)
>>>>>>>>>>>>>>> so we must decide what to do with libgnutls. Although I'm not 
>>>>>>>>>>>>>>> friend
>>>>>>>>>>>>>>> of static linking it seems we have to link Xvnc statically 
>>>>>>>>>>>>>>> against
>>>>>>>>>>>>>>> libgnutls to avoid compatibility issues.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I also created two patches which add -dridir and -xkbcompdir
>>>>>>>>>>>>>>> parameters to Xvnc. Those parameters should be determined same 
>>>>>>>>>>>>>>> way as
>>>>>>>>>>>>>>> -fp parameter in vncserver script and passed to Xvnc.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After vncserver gets improved UNIX code is ready for the alpha
>>>>>>>>>>>>>>> release, in my opinion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards, Adam
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>>>>>>>> and start using them to simplify application deployment and
>>>>>>>>>>>>>> accelerate your shift to cloud computing.
>>>>>>>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> Tigervnc-devel mailing list
>>>>>>>>>>>>>> Tigervnc-devel@lists.sourceforge.net 
>>>>>>>>>>>>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>>>>>> and start using them to simplify application deployment and
>>>>>>>>>>>> accelerate your shift to cloud computing.
>>>>>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Tigervnc-devel mailing list
>>>>>>>>>>>> Tigervnc-devel@lists.sourceforge.net 
>>>>>>>>>>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>>>>> and start using them to simplify application deployment and
>>>>>>>>>>> accelerate your shift to cloud computing.
>>>>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Tigervnc-devel mailing list
>>>>>>>>>>> Tigervnc-devel@lists.sourceforge.net 
>>>>>>>>>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>>>> and start using them to simplify application deployment and
>>>>>>>>>> accelerate your shift to cloud computing.
>>>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Tigervnc-devel mailing list
>>>>>>>>>> Tigervnc-devel@lists.sourceforge.net 
>>>>>>>>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>>> and start using them to simplify application deployment and
>>>>>>>>> accelerate your shift to cloud computing.
>>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Tigervnc-devel mailing list
>>>>>>>>> Tigervnc-devel@lists.sourceforge.net 
>>>>>>>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Start uncovering the many advantages of virtual appliances
>>>>>>>> and start using them to simplify application deployment and
>>>>>>>> accelerate your shift to cloud computing.
>>>>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>>>> _______________________________________________
>>>>>>>> Tigervnc-devel mailing list
>>>>>>>> Tigervnc-devel@lists.sourceforge.net 
>>>>>>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>>>>>>> -- 
>>>>>>> *Robert Goley*
>>>>>>>
>>>>>>> FOSS Implementation Specialist
>>>>>>> Toll Free: (800) 338-4984
>>>>>>> Local: (770) 479-7933
>>>>>>> Fax: (770) 479-4076
>>>>>>> www.openrda.com <http://www.openrda.com>
>>>>>>>
>>>>>>> /America's only Free & Open Source fund accounting software company./
>>>>> -- 
>>>>> *Robert Goley*
>>>>>
>>>>> FOSS Implementation Specialist
>>>>> Toll Free: (800) 338-4984
>>>>> Local: (770) 479-7933
>>>>> Fax: (770) 479-4076
>>>>> www.openrda.com <http://www.openrda.com>
>>>>>
>>>>> /America's only Free & Open Source fund accounting software company./
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Start uncovering the many advantages of virtual appliances
>>>>> and start using them to simplify application deployment and
>>>>> accelerate your shift to cloud computing.
>>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Tigervnc-devel mailing list
>>>>> Tigervnc-devel@lists.sourceforge.net 
>>>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>>>> ------------------------------------------------------------------------------
>>>> Start uncovering the many advantages of virtual appliances
>>>> and start using them to simplify application deployment and
>>>> accelerate your shift to cloud computing.
>>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>> _______________________________________________
>>>> Tigervnc-devel mailing list
>>>> Tigervnc-devel@lists.sourceforge.net 
>>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>>> -- 
>>> *Robert Goley*
>>>
>>> FOSS Implementation Specialist
>>> Toll Free: (800) 338-4984
>>> Local: (770) 479-7933
>>> Fax: (770) 479-4076
>>> www.openrda.com <http://www.openrda.com>
>>>
>>> /America's only Free & Open Source fund accounting software company./
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Tigervnc-devel mailing list
>>> Tigervnc-devel@lists.sourceforge.net 
>>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
>> ------------------------------------------------------------------------------
>> Start uncovering the many advantages of virtual appliances
>> and start using them to simplify application deployment and
>> accelerate your shift to cloud computing.
>> http://p.sf.net/sfu/novell-sfdev2dev
>> _______________________________________________
>> Tigervnc-devel mailing list
>> Tigervnc-devel@lists.sourceforge.net 
>> <mailto:Tigervnc-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
> 
> -- 
> *Robert Goley*
> 
> FOSS Implementation Specialist
> Toll Free: (800) 338-4984
> Local: (770) 479-7933
> Fax: (770) 479-4076
> www.openrda.com <http://www.openrda.com>
> 
> /America's only Free & Open Source fund accounting software company./
> 
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> 
> 
> 
> _______________________________________________
> Tigervnc-devel mailing list
> Tigervnc-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tigervnc-devel


------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel

Reply via email to