1) Changed "cp -a" to "cp -RPp" for bsd compat (needed for "server" USE flag) 2) Tested both vncviewer and vncserver Requesting keyword ~x86-fbsd with this new ebuild (to be attached). Reproducible: Always
Created attachment 119148 [details, diff] vnc-4.1.2-r3.ebuild (this is a diff)
Created attachment 119171 [details, diff] files/vnc-4.1.2-freebsd.patch Patch to create xauth cookie on FreeBDS without the need for "mcookie" (only available in Linux).
Created attachment 119173 [details, diff] vnc-4.1.2-r3.ebuild (diff) Incorporate patch that allows creation of xauth cookies on FreeBSD
Adding maintainer to CC
Patch and ebuild added, thanks. Keyword it :)
Keyworded (vnc-4.1.2-r3). Thanks!
wouldnt it be cleaner to try and use `mcookie` and if that fails, fall back to doing rand ? that way there would be no direct dependency on FreeBSD
Vapier, that sounds like it would work fine and yes, potentially then not be OS-based. The only downside I can think of is that by doing this, the Linux archs would either use mcookie or the other method, depending on if mcookie were installed. Maybe this doesn't matter, but there might be a good reason to have predictable cookie generation on a given arch. If so, it would probably be good to have vnc RDEPEND on the package containing mcookie...
which oddly enough is the util-linux package ...
Are you suggesting that we leave it as-is but that RDEPEND depend on util-linux for linux only? Or do you feel that this should be done at runtime by detecting a failure with mcookie? I'm re-assinging to Raúl for now, since he did the patch checkin and may want to weigh in on this.
the runtime code should see if mcookie works and if it does, use it ... otherwise it should generate its own considering the output is simply a md5 hash, there might be a better way than the current rand() ... maybe grab a few bytes from /dev/random and run md5 on that i dont think we need a direct depend on util-linux in RDEPEND since that package is required in the system target for all Linux profiles
Raúl, Just looking back at this bug; I think it is fixed, unless you had input (see comments 8-11). In other words, you can probably close this out unless you want to revisit. -Thanks, Joe
net-misc/vnc is going away
