Recent posts on both Yocto's ML and here mentioned this issue, but I prefer to post in a new thread, since it's possible that the main focus of those thread (sharing sstate-cache between multiple users) might somewhat have shadowed what IMHO seems indeed an issue with directories permissions in sstate-cache.
What I observed on at least three different build hosts is quite simple: the permissions directories in sstate-cache/ are not uniform. Most of them are 775, but some are 755. This happens with fresh builds (all by the same user) and can be observed on master and morty branches for sure (not verified with pyro). Anyone else seeing this? It might have been unnoticed, or you might have an explanation to state this is normal, but I'd be very surprised if you told me I'm alone in seeing this. Between the hosts that showed this behaviour I have Ubuntu 16.04 boxes (either baremetal or Virtualbox VMs) and the crops/poky-container running on OSX native docker implementation. After noticing this, I got a look at sstate.bbclass, which I believe is the code responsible for actually creating those hierarchies. The following snippet seems to be the place where, regardless of the process' umask, bitbake should ensure sstate-cache subdirs are created with 775 permissions (by changing the process' umask to 002). Am I missing other places where this is handled indeed? omask = os.umask(0o002) if omask != 0o002: bb.note("Using umask 0o002 (not %0o) for sstate packaging" % omask) sstate_package(shared_state, d) os.umask(omask) Now, I'd don't feel confident enough with the code to push my investigation further, than I'm writing this to hopefully have someone more experienced looking at it and help figuring out what's going on. Any thought? Should I file it as a bug?
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core