THE PROBLEM: The problem is that distcc-2.7's source relies on a $TMPDIR envvar to store statistics info. But ebuild.sh sets this to some place distccmon can't detect (inside "emerge" $TMPDIR is different than $TMPDIR outside "emerge"). THE FIX: A separate envvar for distcc to rely on: $DISTCC_TMPDIR and a patch to make it work - and a new ebuild to incorporate the patch. Both the new ebuild and patch will be attached. The patchfile goes in ${FILESDIR} :-)
Created attachment 13421 [details] Updated ebuild Updated ebuild, with patch command and einfo advising about the new monitor programs.
Created attachment 13422 [details, diff] Patchfile for updated ebuild ${FILESDIR} ;-)
Created attachment 13427 [details] Updated ebuild, fixed $Header (oops) hate when that happens. :)
Also... When using this patch compiling things outside of Portage distcc will not support the $TMPDIR envvar because it was replaced (by the patch) with a $DISTCC_TMPDIR envvar. Hopefully this will be fixed by the distcc team soon (maybe /var/tmp/distcc...).
Two points: A better patch would be to first check DISTCC_TMPDIR, and if that doesn't exist, fall back to using TMPDIR. However, this is probably moot due to the following. The version in CVS has just changed where it puts its state files from $TMPDIR/distcc_HOST_UID/state/ to $HOME/.distcc/state/. If the user is building as the protage user, the HOME dir is in /var/tmp/portage/homedir. Thus, we have a similar (but simpler) problem in finding the emerge state files (compared with the unpatched problem of dealing with emerge's per- package TMPDIR value). So, in the next version of distcc we will be able to do this: HOME=/var/tmp/portage/homedir distccmon-text and it will report the current ebuild status (this assumes that the value of $PORTAGE_TMPDIR is /var/tmp). So, I don't think we'll need a patch like this for the next version. It might be nice to have a helper script to set HOME appropriately for a single command, though. Something like this, maybe? emergemon text (calls distccmon-text with HOME set right) emergemon gnome (calls distccmon-gnome with HOME set right)
You're right about the checking of TMPDIR and DISTCC_TMPDIR. However, I still think that the preferred way to launch the monitor programs would still be to use sudo. `sudo -u portage distccmon-{text xor gnome}` and you don't have to bother resetting envvars. Using sudo will eliminate the need for any type of bash script or other method to mangle $HOME. In this .ebuild I even added a RDEPEND for sudo (though I suppose technically its not required) and added a few einfo lines to the effect: use sudo -u portage. I think the next version of distcc will mark this bug as irrelevant by using smarter state directory positioning.
The problem with the sudo command you suggest (when used with the next version of distcc) is that sudo doesn't change the value of HOME in the environment. To do that the user would have to also add the -H option, like this: sudo -H -u portage distccmon-text The next problem is that the home-dir listed in the /etc/passwd file is probably not set right -- it's certainly not right on my systems. It would have to be set to the value of $PORTAGE_TMPDIR/portage/homedir, and it's set to just /var/tmp/portage in my /etc/passwd file (which lacks the /homedir suffix, and $PORTAGE_TMPDIR is not /var/tmp on my systems). So, we should either figure out a way to get the portage-user's home-dir fixed in the passwd file, come up with some other way to force the value of HOME, or just "punt" and tell the user to tweak/maintain the portage-user's entry in the passwd file themselves.
That's odd. For me, just -u portage is sufficient. Zwelch, you wanna edit the ebuild to include -H ? Your /etc/passwd file should have a homedir for portage and it should read something like like: portage:x:250:250:portage:/var/tmp/portage:/bin/false
Lisa, I assume that the reason you don't need to use -H is that you aren't using the CVS version of distcc (i.e. your ebuild builds version 2.7). Please see comment 5 for the upcoming change in the *next* release of distcc. As for the passwd entry you cited, it contains exactly the same wrong home-dir setting that I mentioned was in my passwd file. It will have to be changed to match the value that is in effect when an ebuild runs (see comment 7) in order for the aforementioned sudo command to be able to set the right HOME value for use with the next distcc release (I believe that your setting will just need "/homedir" appended unless you've customized the PORTAGE_TMPDIR setting in /etc/make.conf). The HOME setting does not affect version 2.7's state dir.
distcc-2.7.1 and distcc-2.8 contain this patch or a variation of it. Hope upstream can get a better fix in the works... </wrangle>
