Bugzilla Bug 178430

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 an attachment (id=119148) [details]
vnc-4.1.2-r3.ebuild  (this is a diff)

Created an attachment (id=119171) [details]
files/vnc-4.1.2-freebsd.patch

Patch to create xauth cookie on FreeBDS without the need for "mcookie" (only
available in Linux).

Created an attachment (id=119173) [details]
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