all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: bokr@bokr.com
To: Josselin Poiret <dev@jpoiret.xyz>
Cc: Julien Lepiller <julien@lepiller.eu>, 60816-close@debbugs.gnu.org
Subject: bug#60816: guix pull ("computing Guix derivation") is not reproducible
Date: Mon, 16 Jan 2023 02:25:08 +0100	[thread overview]
Message-ID: <20230116012508.GA2776@LionPure> (raw)
In-Reply-To: <87r0vvkgr0.fsf@jpoiret.xyz>

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





  reply	other threads:[~2023-01-16  1:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-14 18:02 bug#60816: guix pull ("computing Guix derivation") is not reproducible Julien Lepiller
2023-01-15 11:54 ` Josselin Poiret via Bug reports for GNU Guix
2023-01-15 13:29   ` Julien Lepiller
2023-01-15 14:35     ` Josselin Poiret via Bug reports for GNU Guix
2023-01-16  1:25       ` bokr [this message]
2023-01-16 11:48       ` Simon Tournier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230116012508.GA2776@LionPure \
    --to=bokr@bokr.com \
    --cc=60816-close@debbugs.gnu.org \
    --cc=dev@jpoiret.xyz \
    --cc=julien@lepiller.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.