Greg Troxel <gdt%lexort.com@localhost> writes:
> distccd: ERROR: --enable-tcp-insecure: unknown option
> distcc[5786] (dcc_readx) ERROR: unexpected eof on fd7
> distcc[5786] (dcc_r_token_int) ERROR: read failed while waiting for token "DONE"
> distcc[5786] (dcc_r_result_header) ERROR: server provided no
> answer. Is the server configured to allow access from your IP address?
> Is the server performing authentication and your client isn't? Does
> the server have the compiler installed? Is the server configured to
> access the compiler?
> distcc[5786] (dcc_build_somewhere) ERROR: failed to distribute and fallbacks are disabled
This turns out to be a cascade of upstream problems:
distcc retains the concept of operating over unauthenticated channels
distccd used to have "--make-me-a-botnet" as an argument to let
distccd run compilers that were not in /usr/lib/distcc (apparently
that path, not $PREFIX/distcc), and otherwise refused to run them.
That was working around 1) running distcc over unauthenticated
channels and 2) attempting to provide compile services to untrusted
callers.
Between 3.3 and 3.4, the argument was changed to --enable-tcp-insecure
(still not very decriptive, but at least trying):
https://github.com/distcc/distcc/pull/296/files
distcc 3.4 (don't know about 3.3) adds this argument when remotely
invoking distccd over ssh, and there is no backwards compat strategy,
so that distcc 3.4 talking to a distcc 3.3 worker fails.
I updated a worker (which normally runs stable branch) to 3.4, and now I
can build.
I conclude that distcc just doesn't work with 3.4 builder and 3.3
workers, and that's an upstream bug, not a pkgsrc bug. Given the
history of upstream choices, it doesn't seem useful to report it there.
Attachment:
signature.asc
Description: PGP signature