| Message ID | 20220114074138.51861-1-jacob.kroon@gmail.com |
|---|---|
| State | Accepted, archived |
| Commit | 32f01e57e1e915e8121609fb48b0b0254e625957 |
| Headers | show |
| Series | sstate: Preserve permissions when extracting tar archive | expand |
Although this is now fixed in master, I was wondering why this doesn't seem to be a problem in dunfell. In dunfell, sstate packages are unpacked with "tar -xvzf", no -p flag, but still my buildhistory doesn't show any noise when doing: bitbake -c cleansstate shadow-native && bitbake shadow-native && bitbake -c clean shadow-native && bitbake shadow-native After dunfell was the switch to tar+zstd, but I don't understand why that would change the extracted permissions. If anyone has got a clue, i'd be interested to know why. Jacob (testing the message reply function from the archived mailing list)
On Sun, 2022-01-16 at 23:28 -0800, Jacob Kroon wrote: > Although this is now fixed in master, I was wondering why this doesn't seem to > be a problem in dunfell. > In dunfell, sstate packages are unpacked with "tar -xvzf", no -p flag, but > still > my buildhistory doesn't show any noise when doing: > > bitbake -c cleansstate shadow-native && bitbake shadow-native && bitbake -c > clean shadow-native && bitbake shadow-native > > After dunfell was the switch to tar+zstd, but I don't understand why that > would > change the extracted permissions. > > If anyone has got a clue, i'd be interested to know why. I think dunfell doesn't have the umask changes I linked to earlier in the discussion? That means it will behave differently but there are probably other permissions issues e.g. a host with your current umask compared to a host with a different one, particularly around the group bits. Cheers, Richard
On 1/17/22 09:40, Richard Purdie wrote: > On Sun, 2022-01-16 at 23:28 -0800, Jacob Kroon wrote: >> Although this is now fixed in master, I was wondering why this doesn't seem to >> be a problem in dunfell. >> In dunfell, sstate packages are unpacked with "tar -xvzf", no -p flag, but >> still >> my buildhistory doesn't show any noise when doing: >> >> bitbake -c cleansstate shadow-native && bitbake shadow-native && bitbake -c >> clean shadow-native && bitbake shadow-native >> >> After dunfell was the switch to tar+zstd, but I don't understand why that >> would >> change the extracted permissions. >> >> If anyone has got a clue, i'd be interested to know why. > > I think dunfell doesn't have the umask changes I linked to earlier in the > discussion? That means it will behave differently but there are probably other > permissions issues e.g. a host with your current umask compared to a host with a > different one, particularly around the group bits. > Yes, that is true. I'll just leave it at that, thanks for clarifying. Jacob
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass index 645377fdd8..8ee32dba2d 100644 --- a/meta/classes/sstate.bbclass +++ b/meta/classes/sstate.bbclass @@ -901,7 +901,7 @@ sstate_unpack_package () { ZSTD="pzstd -p ${ZSTD_THREADS}" fi - tar -I "$ZSTD" -xvf ${SSTATE_PKG} + tar -I "$ZSTD" -xvpf ${SSTATE_PKG} # update .siginfo atime on local/NFS mirror if it is a symbolic link [ ! -h ${SSTATE_PKG}.siginfo ] || touch -a ${SSTATE_PKG}.siginfo 2>/dev/null || true # update each symbolic link instead of any referenced file
This is done by default when tar is run by the superuser, but for native recipes the corresponding task is not run as root under pseudo, so pass the flag explicitly. Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com> --- meta/classes/sstate.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)