[OE-core] [PATCH] sstate.bbclass: preserve time when unstaging files

[Richard Purdie]

On Mon, 2012-10-29 at 22:41 +0100, Enrico Scholz wrote:
> Richard Purdie <richard.purdie at linuxfoundation.org> writes:
> 
> >> >> >> But the real bug is the time mismatch in the autobuilders, isn't it?
> >> >> >> And this can/should be solved by synchronizing time by ntp on them
> >> >> >> instead of applying dirty hacks like resetting file dates.
> > ...
> > Imagine system A generates the sysroot headers with a time ahead of
> > system B. These are packaged up into an sstate tarball. System B which
> > has a clock at some time behind system A then downloads and uses them
> > so the sysroot headers become some time in the future.
> 
> This can not happen when both machines are synchronizing their time with
> ntp.  Drift to stratum-1 machine is usually <1ms in local networks and
> <50ms for remote ones (--> see 'ntpq' -> pe output).
> 
> Nothing, which can cause the problem described by you.

I have already agreed that this cannot happen if the machines are in
good sync via ntp, I'm not arguing with that.

> > The alternative is to mandate *every* system that builds are run on
> > use ntp
> 
> Yes; a common timesource is mandatory for so nearly every distributed
> system.  Even windoze enables (s)ntp clients by default (although its
> daily synchronization is just a bad joke) and I remember Fedora/Ubuntu
> enabling it by default too.
> 
> 
> > and add checks to sanity.bbclass to this effect since someone might
> > try using a sstate feed with a bad clock. This would cause no end of
> > problems, not least with corporate filewalls
> 
> Every non-trivial network has local ntp servers which are used by clients
> there.

Most of the time I get email from people who are technically clued up on
decent non-trivial networks (say Intel). The amount of emails I get
where the sender's machine's clock is way out is surprisingly high.

That alone suggests that relying on people to setup ntp is not going to
work.

> > and hurt usability of the project
> 
> How common is the distributed autobuilder setup?  How many of these
> installations do not use ntp?

The local.conf.sample details how a user can use a public sstate feed.
If at the same time they don't ensure their clock is correct, things
will break in unexpected and nasty ways.

The yocto autobuilder infrastructure had some misconfiguration and
failed due to ntp not working properly and the clocks going out of sync.
Having seen the problem there, spent many hours tracking it down and
asked for it to get fixed, the Intel autobuilders then suffered exactly
the same issue for different reasons (effectively firewalls again
though). All the evidence I have says relying on working ntp setups is
not good enough in the real world much as you, I and others wish it were
so.

There is a simple and easy way to avoid this problem with tar -m so I
think we have a good justification for that.

Cheers,

Richard