If I try to emerge lm_sensors 2.10.1 or 2.10.3 then I get the message: "You may safely ignore any errors from compilation that contain "No such file or directory" references." followed by a bunch of "No such file or directory" messages for *.[hrla]d What then happens is that the ebuild tries to generate these files using commands similiar to: sed -e 's@^\(.*\)\.o:@lib/chips.ld lib/chips.lo: Makefile '`dirname lib/chips.ld`/Module.mk' @' > lib/chips.ld i686-pc-linux-gnu-gcc -M -MG -I. -Ikernel/include -I/usr/src/linux/include -DSYSFS_SUPPORT -fpic -Wall -O2 -O2 -pipe -fomit-frame-pointer -march=athlon64 -msse3 lib/error.c | \ The files are successfully created by the ebuild but it gets stuck in an infinite loop generating the same files over and over. I can see the timestamps of the *.[hrla]d being updated but they have the same contents each time. My kernel version is 2.6.19 but I don't think that is related. What I think is causing the problem is that this machine is a diskless client which mounts it's entire filesystem over NFSv4. I can successfully emerge the exact same ebuild on my regular desktop machine. I have also successfully emerged at least 20 other ebuilds on the diskless machine without any trouble Reproducible: Always Steps to Reproduce: 1.emerge --oneshot lm_sensors Actual Results: Compile loops forever, does not finish. Expected Results: Compile finishes.
Once I realised that this bug was NFS related, I found these 2 old bugs in the lm-sensors tracker: http://www.lm-sensors.org/ticket/255 http://www.lm-sensors.org/ticket/1023 The problem turned out to be that the system clock on the diskless client was not in sync with the system clock on the NFS server. The issue went after after installing ntp on the client.
