2450 2012-05-12 00:53:17 +0000 quilt-native siginfo file name matches despite cache file being unused/unusable ? 2012-06-19 15:07:02 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto unspecified x86 Multiple VERIFIED NOTABUG (P1)(Scheduled) Medium normal 1.3 M1 1 josh richard.purdie poky.bs.watcher poky.watcher sgw song.liu --- --- --- oldest_to_newest 21315 0 josh 2012-05-12 00:53:17 +0000 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. 21317 1 richard.purdie 2012-05-12 07:52:54 +0000 Was this not a race? Did the file from a not exist at the time the build started, hence it wasn't used? 21342 2 josh 2012-05-14 15:59:34 +0000 (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. 21498 3 richard.purdie 2012-05-21 14:13:49 +0000 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. 22341 4 josh 2012-06-19 15:07:02 +0000 Sounds reasonable.