Bug 2450

Summary: quilt-native siginfo file name matches despite cache file being unused/unusable ?
Product: [Build System, Metadata & Runtime] Meta-yocto Reporter: Joshua Lock - Disabled <josh>
Component: meta-yoctoAssignee: Richard Purdie <richard.purdie>
Status: VERIFIED NOTABUG QA Contact:
Severity: normal    
Priority: Medium CC: poky.bs.watcher, poky.watcher, sgw, song.liu
Version: unspecified   
Target Milestone: 1.3 M1   
Hardware: x86   
OS: Multiple   
Whiteboard: (P1)(Scheduled)
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Joshua Lock - Disabled 2012-05-12 00:53:17 UTC 
When trying to work through some sstate sharing issues I had two users who are members of the same group building in different paths and b using a's sstate-cache.

When b is building native packages the do_populate_sysroot_setscene() calls fail, as is to be expected (I believe), and BitBake sets off building my pseudo and -native recipes.

quilt-native appears to be the first to compile and install and all seems well until it tries to create the siginfo file, this fails as the file already exists from user a.

I would have assumed that if the sstate file from a couldn't be used the siginfo filename, which includes something which looks like a hash, would be different and that b would create a new siginfo file rather than trying to overwrite a's.

a's sstate-cache is rw-rw-r-- so b can create files in a's sstate-directory but the siginfo files are created rw-r--r-- which seems fine except for in the above issue.

I'm not sure what the right solution is here so hoping for some feedback/suggestions.
Comment 1 Richard Purdie 2012-05-12 07:52:54 UTC 
Was this not a race? Did the file from a not exist at the time the build started, hence it wasn't used?
Comment 2 Joshua Lock - Disabled 2012-05-14 15:59:34 UTC 
(In reply to comment #1)
> Was this not a race? Did the file from a not exist at the time the build
> started, hence it wasn't used?

It wasn't a race. a's build had completed long before b's even started.
Comment 3 Richard Purdie 2012-05-21 14:13:49 UTC 
I think what happened here was that some of the task checksums matches but not all for all tasks. Bitbake concluded it had to rerun other tasks completely to finish the build. I therefore think the behaviour is expected but we need to be more careful with permissions. I believe patches addressing the permissions have been fixed so this issue should be resolved.
Comment 4 Joshua Lock - Disabled 2012-06-19 15:07:02 UTC 
Sounds reasonable.