Bug 8996 - When using the sstate, the mtime time of the files stored doesn't seem to be preserved.
Summary: When using the sstate, the mtime time of the files stored doesn't seem to be ...
Status: VERIFIED FIXED
Alias: None
Product: BitBake
Classification: Build System, Metadata & Runtime
Component: bitbake (show other bugs)
Version: unspecified
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.1 M3
Assignee: Richard Purdie
QA Contact: Bogdan Alexandru Voiculescu
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-01-25 14:12 UTC by Igor Stoppa
Modified: 2016-05-09 14:26 UTC (History)
3 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Stoppa 2016-01-25 14:12:08 UTC 
Given a recipe that generates files and stores them in the sstate,
it seems that in successive builds, the timestamp of the file fished from the sstate is assigned based on when the build was executed, rather than the time at which the files were originally built and pickled.


Easy way to reproduce it:

after building an image that generates intel-microcode, from the build directory:


ls -la ./tmp-glibc/deploy/images/intel-corei7-64/microcode_*.cpio

-rwxr-xr-x 2 igor users     693248 Jan 22 15:03 microcode_20151106.cpio


then "bitbake -c clean intel-microcode" and "bitbake intel-microcode"

ls -la ./tmp-glibc/deploy/images/intel-corei7-64/microcode_*.cpio

-rwxr-xr-x 2 igor users 693248 Jan 25 15:46 microcode_20151106.cpio


This can cause problems with sw that relies also on the timestamp for fingerprinting a file.
Comment 1 Richard Purdie 2016-01-25 14:35:32 UTC 
http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/sstate.bbclass?id=2d89cff42af2bb0049224bfaaebaa2b21966169f is where this was introduced.

$ ls -la tmp/deploy/images/qemux86/bzImage* -la
lrwxrwxrwx 1 richard richard      75 Jan 25 14:06 tmp/deploy/images/qemux86/bzImage -> bzImage--4.1.15+git0+46bb64d605_788dfc9859-r0.32-qemux86-20160125140441.bin
-rw-r--r-- 2 richard richard 6976432 Jan 12 12:43 tmp/deploy/images/qemux86/bzImage--4.1.15+git0+46bb64d605_788dfc9859-r0.12-qemux86-20160112123145.bin
-rw-r--r-- 2 richard richard 6976432 Jan 15 12:55 tmp/deploy/images/qemux86/bzImage--4.1.15+git0+46bb64d605_788dfc9859-r0.15-qemux86-20160115124134.bin
-rw-r--r-- 2 richard richard 6976432 Jan 15 16:02 tmp/deploy/images/qemux86/bzImage--4.1.15+git0+46bb64d605_788dfc9859-r0.18-qemux86-20160115155708.bin

$ rm tmp/stamps/qemux86-poky-linux/linux-yocto/4.1.15+gitAUTOINC+46bb64d605_788dfc9859-r0.do_deploy.*
$ rm -la tmp/deploy/images/qemux86/bzImage* 
$ bitbake virtual/kernel -c deploy

$ ls -la tmp/deploy/images/qemux86/bzImage* -la
lrwxrwxrwx 1 richard richard      75 Jan 25 14:23 tmp/deploy/images/qemux86/bzImage -> bzImage--4.1.15+git0+46bb64d605_788dfc9859-r0.32-qemux86-20160125140441.bin
-rw-r--r-- 2 richard richard 6976432 Jan 25 14:23 tmp/deploy/images/qemux86/bzImage--4.1.15+git0+46bb64d605_788dfc9859-r0.12-qemux86-20160112123145.bin
-rw-r--r-- 2 richard richard 6976432 Jan 25 14:23 tmp/deploy/images/qemux86/bzImage--4.1.15+git0+46bb64d605_788dfc9859-r0.15-qemux86-20160115124134.bin
-rw-r--r-- 2 richard richard 6976432 Jan 25 14:23 tmp/deploy/images/qemux86/bzImage--4.1.15+git0+46bb64d605_788dfc9859-r0.18-qemux86-20160115155708.bin

where as once the above patch is reverted, the timestamps are preserved as expected.
Comment 3 Bogdan Alexandru Voiculescu 2016-05-04 13:38:56 UTC 
Verified on master f7b520878babbaa7527151f22c031ae160512753 using RP's steps.