These packages were built with libjpeg-turbo 1.2.0:
http://sourceforge.net/projects/libjpeg-turbo/files/1.2.0/

Package signatures

To ensure the integrity of the VirtualGL binary packages, the RPM and DEB files and the source tarball are signed using the following key:
http://www.VirtualGL.org/key/VGL-GPG-KEY-1024
http://pgp.mit.edu/pks/lookup?op=get&search=0x6BBEFA1972FEB9CE
and the Windows installers are signed using a code signing certificate.

2.3.1

Significant changes relative to 2.3:

1. Worked around a segfault that occurred when running CoreBreach.

2. VirtualGL now properly handles implicit deletion of windows/subwindows via XCloseDisplay(), implicit deletion of subwindows via XDestroyWindow(), and explicit deletion of subwindows via XDestroySubwindows(). This specifically addresses BadDrawable errors that occurred when running certain applications in WINE 1.3.34 and later.

3. Fixed a crash in glXCreateGLXPbufferSGIX() that occurred when a NULL attribute list pointer was passed to it.

4. VirtualGL should now build and run properly on FreeBSD.

5. VirtualGL now works properly with applications that dynamically load libX11. This specifically fixes several issues that occurred when running SDL-based applications against a version of libSDL that was configured with --enable-x11-shared.

6. Changed the Debian package names to lowercase ("virtualgl" and "virtualgl32") to avoid an issue whereby the package was always being installed, even if the installed version was up to date.

7. vglserver_config now works properly with KDM on RHEL/CentOS 5 systems.

8. Added a new option (VGL_GLFLUSHTRIGGER) that, when set to 0, will cause VirtualGL to ignore glFlush() commands from the 3D application. This is intended for rare applications that do front buffer rendering and use glFlush() as an "intermediate" synchronization command but then subsequently call glFinish() to indicate the end of the frame.

9. Fixed an issue whereby drag & drop operations in certain Java applications would cause VNC servers (any VNC server, not just TurboVNC) to hang whenever the Java application was run using VirtualGL.