bug#60816: guix pull ("computing Guix derivation") is not reproducible

[bokr]

Hi,

On +2023-01-15 15:35:31 +0100, Josselin Poiret via Bug reports for GNU Guix 
wrote:
> Hi again Julien,
> 
> Julien Lepiller <julien@lepiller.eu> writes:
> 
> > it seems that on one machine, my .cache/guix/checkouts got polluted by
> > uncommited files. I have no idea why they're there, but cleaning them
> > should solve my issue, thanks!
> 
> It's not the first time we've seen this, we could probably consider
> adding a git clean after the reset in switch-to-ref.
> 
> Best,
> -- 
> Josselin Poiret

Could wrong timestamps on pushed files cause problems?

E.g., if you were working offline on a laptop where
    cat /proc/driver/rtc
was significantly wrong at boot time, perhaps due to flaky CMOS battery,
or error in init specs? If you didn't connect to the internet and get
synced, couldn't you wind up with files with bad time stamps?

(I think I can dig up evidence of that, when I didn't connect,
though I don't show it here).

Could some Makefile action or some date-sensitive find or
    if [[ file1 -nt file2 ]] then <action> 
be wrongly triggered and leave mystery files around?

IWT synchronizing distributed monotonic time has to have been solved
a long ago, but old unnoticed errors do seem to wake up sometimes
in new circumstances.

I have been having mystery problems with time, which I have yet to
diagnose properly. One theory that matches some symptoms is if there
is a virtualized /proc/driver/rtc which gets a bogus value temporarily,
which gets accessed and stored by whatever stores time as boot time for
who -b to see forever (until shutdown) --
but date and other time functions see the virtual /proc/driver/rtc every
time, not a cached value, so they get corrected shortly after internet
is connected.

But what happens to file time stamps if you don't connect
to the internet for a long time?

BTW,I see the bad time at the top of the screen right after boot
but before reaching login, and IIRC it will currect to local without
logging in if I plug in the internet dongle.

Shown below I just booted from cold power-off, with 99% main battery,
about 17:20, so how to explain bogus who -b system boot time of 07:53
this morning? From that timee uptime at 17:20:06
would be: 9hrs 27min 6sec, not "1:14" (1hr 14min))

Well, I guess the 9 hours could be explained by root having a different
idea of locale at pre-internet boot time, but the 27min 6 sec?  

--8<---------------cut here---------------start------------->8---
who -b; uptime;date -Ins;grep rtc /proc/driver/rtc
         system boot  2023-01-15 07:53
 17:20:06 up  1:14,  1 user,  load average: 0.00, 0.08, 0.15
2023-01-15T17:20:06,768027575+01:00
rtc_time        : 16:20:06
rtc_date        : 2023-01-15
--8<---------------cut here---------------end--------------->8---

Also some anomalies in dmesg and journalctl -b, but inconclusive for me ;/

I noticed the bad "who -b" times because whenever my ~/.bash_profile
sees a change as I log in, it uses the date to create a new scratch
"boot-session" directory and updates a symbolic link to it at ~/bs
like stat -c %N ~/bs shows:
    '/home/bokr/bs' -> '/home/bokr/BS/bs20230115_0753'
which is annoyingly wrong. It also makes a link to the previous ~/bs
in the new, like
    '/home/bokr/bs/pbs' -> '../bs20230113_0427'
(showing some insomnia ;/ )

but if I cd ~/bs PS1 will display a nice short prompt :)
--8<---------------cut here---------------start------------->8---
[01:53 ~/bs]$ cd ~/bs
[01:53 ~/bs]$ realpath .
/home/bokr/BS/bs20230115_0753
[01:53 ~/bs]$ realpath ~/bs
/home/bokr/BS/bs20230115_0753
[01:54 ~/bs]$ 
--8<---------------cut here---------------end--------------->8---

HTH & SFTN if this is not useful or relevant.
--
Regards,
Bengt Richter