It's really not clear which parts of the distcc guide pertain to the machine that's being set up to use distcc as its compiler and which parts pertain to the machines that are lending cpu power. For example, immediately after code listing 2.6 (which presumably is for the machine which will use distcc as its compiler), it says "don't forget to start the distcc daemon" -- but which machine(s) should be running this daemon? A good idea would be to separate the whole thing into two sections: one for distcc crunchers and one for distcc clients. Of course they both use the same ebuild currently (though there's been some discussion on gentoo-dev about separating these out with client/server USE flags), but making it clear which parts of the configuration are necessary for which ends of distcc would help a lot. Reproducible: Always Steps to Reproduce:
If someone on the docs team wants to restyle the distcc docs be my guest. However I'd like to read a new version before it's comitted. Thanks.
This has been lurking for too long now without extra input. Marking as LATER.
the problem here is that the "host" and "client" are basically the same. distcc is a network which can allow for multiple hosts and clients. also, a client can become a host at any moment... however, it does need some tweaking. i'm working on it now
Created attachment 59541 [details, diff] distcc.xml.diff the patched version is available for viewing in a browser from http://neverland.ncssm.edu/~smithj/gentoo/distcc-modded.html all i really did was clean it up, make it clearer in a number of sections, reorganize, and add a few warnings. it should, however, clear up the host/client issue
Created attachment 59542 [details] distcc-modded.xml the entire xml source, as lisa requested on irc
I'll read this over and see if it's suitable from a distcc standpoint.
*** Bug 96007 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > I'll read this over and see if it's suitable from a distcc standpoint. any word?
The diff failed to apply on the CVS co a few minutes ago, so I'm reviewing it now. I'm not 100% pleased with the reordering and parts of it are factually inacurate.
Created attachment 61267 [details] Lisa's attempt This version is rewritten a bit and different from the previous attachments but has a bit of it. Probably needs to credit Jonathan Smith with reviewer.
(In reply to comment #10) > Probably needs to credit Jonathan Smith with reviewer. i don't care; i just want better docs :-)
(In reply to comment #10) > Created an attachment (id=61267) [edit] > Lisa's attempt Your file is the same as the one already online. Looks like you uploaded the original.
Argh, crap!! I'll have to do this again..
lisa: any word?
Created attachment 61784 [details] ready to try again. Please read and let me know how this addresses outstanding issues.
(In reply to comment #15) > ready to try again. > > Please read and let me know how this addresses outstanding issues. lisa: i'm not sure how you did it, but you posted an unchanged file again, right down to the cvs header a diff would be nice :-)
Created attachment 62037 [details, diff] If THIS doesn't work I'm going to copy it to disk and snail mail it!
lisa: you silly goose, you forgot date bump
Pfft. I think the docs team is capable of entering the correct date. ;)
lisa: you missed a few things, including proper line-breaks, but i fixed them fixed
(In reply to comment #18) > lisa: you silly goose, you forgot date bump Bah. That's your thingy ;) The person who commits should check date + version.
fox2mike: no responding to already-closed bugs... it makes me think i have to actually _do_ something :-P
