On Mon, May 30, 2005 at 01:02:44AM +0200, Marek Habersack wrote: > On a system with correct RTC settings, with no bugs in the touch(1) utility > this cannot happen. It can happen only when make(1) detects that the .c file > to be generated from a .cmod source is older than the .cmod source. > precompile.sh is called only in such situation or when running 'make export' > on the CVS sources - in the latter case, the .c timestamp is newer than that > of the .cmod. Therefore, please check your RTC and the touch(1) utility > (there was a problem with it not working properly on hppa and mips long time > ago, perhaps you stumbled across the same/similar problem). I haven't been > able to reproduce the problem as well so I'm downgrading the bug severity to > normal. Please do not raise it until you can show us a reproducible scenario > to reproduce the bug, thanks
This bug is quiet real and very reproducible and is also already fixed in an NMU. It has nothing to do with a broken RTC or touch. What it has to do with is that there is a timestamp skew problem introduced by the debian diff. Like you said it yourself, this happens when the .c file is older than the .cmod file. And on extracting the sources it is older, because the debian diff has the patched .c file in it before the .cmod file. If you look in the debian diff (of -3) you'll notice that kerberos.c is in it before kerberos.cmod, so kerberos.c is older than kerberos.cmod. On repackaging it, it might actually be in a different order. You might not always notice that it's older because you're so fast in applying the patch that you can't detect the time difference between them. This mean it can show up more easily on slower arches. But it also shows up on a 2.6 kernel because it has microsecond resolution on timestamps of files as long as they are in memory. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
