Just a notice: I've compared 2 weeks ago the behaviour of vnc (from Centos 5)
and tightvnc (version 1.3.9 from rpmforge, still on the same Centos 5). Despite
all our efforts (we tried absolutely all available optimization switches, such
as -depth 8, -compresslevel 9, -quality 4 ) access via tightvnc to a remote
server (which is completely out of my reach; I assume it runs RHEL, no idea
about the version ) was painfully slow (delays in the terms of seconds). Using
vnc -LowColourLevel 2 brought things closer to normality. RTT were in the
100-110 ms range in all cases.
Does this newer version improve things ?

few notes
- you can use "svn export" instead of "svn checkout" (or a even script like http://fedora.danny.cz/fedora-getsvn), the source archive will be smaller, but when you are using upstream released snapshots, use them
- the EVRs in Obsoletes/Provides are inconsistent between main package and -server subpackage and I don't think that the main package should contain Obsol/Prov for vnc-server
- better use --with-os-name="Fedora" in xserver's %configure (instead of "Fedora 11")
- replace /etc with %{_sysconfdir}, /etc/rc.d/init.d with %{_initddir} in %build and %install sections
- don't add X-Red-Hat-Extra into desktop file, fix the file directly instead of using command line options, use fedora as vendor, missing BR: desktop-file-utils - more about desktop files at https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files

Yet 2 little issues
- the License tag should be GPLv2+ (sorry I missed that in the first round)
- include instructions for getting the sources - see
https://fedoraproject.org/wiki/Packaging/SourceURL#Using_Revision_Control
(svn export https://vnc-tight.svn.sourceforge.net/svnroot/vnc-tight/trunk -r %{revision} tightvnc; tar czvf ...)
And one suggestion - can you move this section
cp -r %{_datadir}/xorg-x11-server-source/* unix/xserver
pushd unix/xserver
for all in `find . -type f -perm -001`; do
chmod -x "$all"
done
patch -p0 < ../xserver.patch
from %build to %prep, because this is in fact source preparation too.
And last thing (not related to the review) could be refreshing the xserver.patch, because it applies quite unclean.

There is little misunderstanding - Adam's intention was to do the move from vnc to tightvnc in F-11, but to achieve that in the time of the CVS request, it was required to ask for F-10 branch whose content will be included in F-10 (but it will remain empty here) and only the content of devel will go into rawhide even when usual devel branch goes into F-to-be-10.

Is it possible to build this package in F-10 branch without "Obsoletes" attribute?
Or is there a problem with that?
I think an empty folder is not a good idea. Also there is an problem, that this package is included in pkgdb:
https://admin.fedoraproject.org/pkgdb/packages/name/tightvnc#Fedora10
I like tightvnc and real-vnc is not what I want.
I know, that I can rebuild this for myself, but It's nicer to have this package in distribution.

(In reply to comment #21)
> Is it possible to build this package in F-10 branch without "Obsoletes"
> attribute?
> Or is there a problem with that?
> I think an empty folder is not a good idea. Also there is an problem, that this
> package is included in pkgdb:
> https://admin.fedoraproject.org/pkgdb/packages/name/tightvnc#Fedora10
>
> I like tightvnc and real-vnc is not what I want.
>
Well, I can build tightvnc for F10 but I don't see reason for it. Current trunk tightvnc is forked RealVNC source - it is completely different from "old" tightvnc 1.2.9 & 1.3.9.