Greg Troxel <gdt%lexort.com@localhost> writes: > distccd: ERROR: --enable-tcp-insecure: unknown option > distcc (dcc_readx) ERROR: unexpected eof on fd7 > distcc (dcc_r_token_int) ERROR: read failed while waiting for token "DONE" > distcc (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 (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.
Description: PGP signature