Fedora Merge Review: vnc http://cvs.fedora.redhat.com/viewcvs/devel/vnc/ Initial Owner: atkac
Build of rawhide SRPM on F-9 fails: In file included from glxdriswrast.c:39: /usr/include/GL/internal/dri_interface.h:43:17: error: drm.h: No such file or directory In file included from glxdriswrast.c:39: /usr/include/GL/internal/dri_interface.h:278: error: expected declaration specifiers or '...' before 'drm_clip_rect_t' /usr/include/GL/internal/dri_interface.h:280: error: expected declaration specifiers or '...' before 'drm_clip_rect_t' /usr/include/GL/internal/dri_interface.h:334: error: expected declaration specifiers or '...' before 'drm_clip_rect_t' /usr/include/GL/internal/dri_interface.h:596: error: expected declaration specifiers or '...' before 'drm_drawable_t' /usr/include/GL/internal/dri_interface.h:604: error: expected declaration specifiers or '...' before 'drm_context_t' make[1]: *** [glxdriswrast.lo] Error 1 make[1]: Leaving directory `/home/limb/rpmbuild/BUILD/vnc-4_1_2-unixsrc/unix/xorg-x11-server-source/glx' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.69026 (%build) License tag should be GPLv2+. Upstream Source is 404. There are 36 patches, with no notes as to upstream status. Can't check BuildRequires, or run rpmlint on RPMS, see above. rpmlint on spec: vnc.spec: W: mixed-use-of-spaces-and-tabs (spaces: line 3, tab: line 128) The specfile mixes use of spaces and tabs for indentation, which is a cosmetic annoyance. Use either spaces or tabs for indentation, not both. Fix. Other than the above, full review is good, no other blockers.
"Old" vnc is going to be replaced by tightvnc package in F11 which has already passed throught review process (bug #445537). vnc is is going to be dead in F11 so I think we don't have to waste time with vnc review. If you think vnc should be reviewed for F10 please reopen.
Please tell on fedora-devel that you are orphaning vnc, maybe there will be takers (for F11). If so, I think that it would be better in any case to have a regular review done, so keeping this closed and not reviewed is the best solution in my opinion.
(In reply to comment #3) > Please tell on fedora-devel that you are orphaning vnc, maybe there will > be takers (for F11). If so, I think that it would be better in any case to > have a regular review done, so keeping this closed and not reviewed is the > best solution in my opinion. +1, but what, functionally, would be the difference between a regular review and a merge review?
(In reply to comment #4) > +1, but what, functionally, would be the difference between a regular review > and a merge review? Not much, except that in Merge reviews it is often very unclear who is the reporter. Also another major difference is that the package is in fedora during the review which removes an incentive for reviewers and submitters.
(In reply to comment #5) > (In reply to comment #4) > > > +1, but what, functionally, would be the difference between a regular review > > and a merge review? > > Not much, except that in Merge reviews it is often very unclear who is > the reporter. Also another major difference is that the package is in > fedora during the review which removes an incentive for reviewers and > submitters. Tell me about it. ;)
(In reply to comment #3) > Please tell on fedora-devel that you are orphaning vnc, maybe there will > be takers (for F11). If so, I think that it would be better in any case to > have a regular review done, so keeping this closed and not reviewed is the > best solution in my opinion. Well, this is not solution. tightvnc is forked vnc so both packages have same code, same binaries etc. So we have to have vnc or tightvnc but not both.
(In reply to comment #7) > (In reply to comment #3) > > Please tell on fedora-devel that you are orphaning vnc, maybe there will > > be takers (for F11). If so, I think that it would be better in any case to > > have a regular review done, so keeping this closed and not reviewed is the > > best solution in my opinion. > > Well, this is not solution. tightvnc is forked vnc so both packages have same > code, same binaries etc. So we have to have vnc or tightvnc but not both. They can be made parallel installable and use alternatives, for example. Or simply have realvnc binaries prefixed. You are orphaning vnc, please follow the procedures.