On 2007/11/08 08:04, Karle, Christopher P wrote: > I wasn't able to find any recent solution to this issue in the > ports mailing list archive.
http://marc.info/?l=openbsd-ports&w=2&r=1&s=amd64+tightvnc&q=b leads to http://marc.info/?l=openbsd-ports&m=117870619707572&w=2 which is your patches updated to run on -current as of then (i.e. 4.2, near enough). > Agreed, but Xf4vnc is not built as a package, which is a barrier > for some. TightVNC is a very familiar solution for many people. The sort of person who will be able to fix any remaining problems (e.g. identifying the various fixes for xf3 to support sparc64 and integrating them to this code) is likely to also be the sort of person who could port Xf4vnc. I was interested in this at one point, but then I got a laptop so VNC server isn't quiite as useful for me any more... I'd be happy for the amd64 fix to go in, but I'd like some way to avoid the current situation of building a broken sparc64 tightvnc-1.xx.tgz before I ask another committer for an ok. No response so far about marking a subpackage as broken for some arch (BROKEN is not subpackage-dependent, it applies to the whole port, and my Makefile skills are not yet sufficient to change this in bsd.port.mk); the best I've been able to come up with so far is to reverse server/viewer i.e. COMMENT-main= client for cross-platform remote desktop access COMMENT-server= cross-platform remote desktop access instead of the existing COMMENT-main= cross-platform remote desktop access COMMENT-viewer= client for cross-platform remote desktop access then we can do MULTI_PACKAGES= -main .if ${MACHINE_ARCH} != "sparc64" MULTI_PACKAGES+=-server .endif Any comments on this idea, anyone?
