sstate: Use -m option to tar when unpacking sstate
PATCH 1/1 sstate: Use -m option to tar when unpacking sstate
We've noticed failures on the project autobuilders where a shared sstate directory is used across multiple builders and the clocks become skewed.
Most of the time this causes harmless building but if this happens where an environment is changed (make install vs make in qt4-x11-free for example), the build can fail.
This avoids modification times in the future and should make builds safer in shared environments sstate was designed for.
---
meta/classes/sstate.bbclass +1 -1
@@ -544,7 +544,7 @@ sstate_create_package () { sstate_unpack_package () { mkdir -p ${SSTATE_INSTDIR} cd ${SSTATE_INSTDIR} - tar -xvzf ${SSTATE_PKG} + tar -xmvzf ${SSTATE_PKG} } # Need to inject information about classes not in the global configuration scope
Richard Purdie <[email protected]>
Quoted 3 lines · writes:
We've noticed failures on the project autobuilders where a shared sstate directory is used across multiple builders and the clocks become skewed.
I think, 'ntp' is a better way to solve this...
Quoted 2 lines
This avoids modification times in the future and should make builds safer in shared environments sstate was designed for.
But this will remove information about the age of (packaged) files, won't it? E.g. previously, I was able to see on the target machine, when a file was modified. It is not a critical feature but often very useful.
Now, the date on image will be either the former date or the date when the staged tarball will be extracted (--> e.g. after 'bitbake -c clean'). Sounds confusing.
meta/classes/sstate.bbclass sstate_create_package () { · line 547
Quoted 2 lines
meta/classes/sstate.bbclass +1
-1- tar -xvzf ${SSTATE_PKG} + tar -xmvzf ${SSTATE_PKG}
Enrico