Ian Jackson writes ("Re: Bug#1093412: Regression in tests with new faketime"):
> Why are we passing NO_FAKE_STAT here?
I UTSL and in reprotest/build.py I see:
# faketime's manpages are stupidly misleading; it also modifies file
timestamps.
# this is only mentioned in the README. we do not want this, it really
really
# messes with GNU make and other buildsystems that look at timestamps.
# set NO_FAKE_STAT=1 avoids this.
> Maybe the problem is that faketime isn't honouring NO_FAKE_STAT.
> I will see if I can confirm...
I have tested and it *does* seem to honour NO_FAKE_STAT.
James Addison writes ("Bug#1093412: Regression in tests with new faketime"):
> Furthermore: performing a copy operation on a file from the source
> when using faketime in debian:unstable appears to reduce the mtime of
> the file by the delta duration each time a copy operation occurs:
>
> $ stat -c '%y' reprotest-0.7.29/reprotest/utils.py
> 2023-02-26 22:10:37.000000000 +0000
> $ NO_FAKE_STAT=1 faketime '+331hours' cp -a
> reprotest-0.7.29/reprotest/utils.py .
> $ stat -c '%y' utils.py
> 2023-02-13 03:10:37.000000000 +0000
> $ NO_FAKE_STAT=1 faketime '+331hours' cp -a utils.py utils2.py
> $ stat -c '%y' utils2.py
> 2023-01-30 08:10:37.000000000 +0000
I have thought about this and I think this behaviour is (now)
expected but probably unintended:
cp will call stat to get the mtime. It gets the real mtime.
Then it will call utime (utimensat in fact) to set the file times.
But faketime fakes utime too! And without FAKE_UTIME=0 (yes,
inconsistent env var) it adjusts the arguments to utime.
utimensat was missing from faketime's repertoire before upstream
commit d90c8c26d345 from 2020-07-28. That was included in 0.9.9 so
*that* isn't the change.
But diffing trixie to sid shows:
+static int fake_utime_disabled = 0;
...
-static int fake_utime_disabled = 1;
So the upstream default has changed. This happened in 2d941a894f4d
"fixes #374 fix compiling without FAKE_STAT". The commit message does
not indicate that this change was intentional.
I will revert this change in sid and see if it helps.
Thanks, James, your report has been very helpful.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
