Richard Purdie <[email protected]> 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. > 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. > and hurt usability of the project How common is the distributed autobuilder setup? How many of these installations do not use ntp? Enrico _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
