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

[Richard Purdie]

On Mon, 2012-10-29 at 20:00 +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.
> >> ...
> >> > Worse, when this does happen the failures are extremely unpredictable
> >> > and hard to debug. It causes things to repeatedly recompile for example,
> >> > even during do_install.
> > ...
> > Set the date stamp of some headers in the target sysroot of some key
> > system components (say glib) to a date about a day in the future,
> 
> Are there really packages which create files dated in the future?
> Perhaps a sanity check should be written which rejects files which are
> newer than their containing directory and/or the time-of-day?
>
> > then clean and rebuild some software that uses glib.
> 
> How will 'tar -m' fix this?  It makes things just worse because the
> files generated with -m are always newer than without -m (in practice,
> time offset between hosts served by ntp is far below 100ms. which is
> enough for the build stages doing the sstage file extraction).

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. You then see the
problem I described previously.

tar -m fixes this by timestamping things at the time of extraction,
thereby removing any issue of the timestamps being in the future. Yes,
we could add a step which iterated over the extracted files and checked
to see if any were in the future and if so, change their timestamps but
it seems a bit overkill when the option to tar resolves all the
problems.

The alternative is to mandate *every* system that builds are run on use
ntp 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 and hurt usability of the
project so we took the other option which fixes things in a way this
should become a non-issue.

Cheers,

Richard