Same problem with 3.5.13. :( Files and directories should be world readable within the tarballs.

I build my packages in a chroot running as root. The build location is readable by my normal user account. When I am testing patches and the patches fail the build script halts. I can't view or browse files in the build area as normal user, which I prefer because my chroot build environment is command line only. Konqueror and Kate are so much more pleasant to use. :) I have to chown the files from within the build environment before I can browse the build area.

I can do that from within my build script, but releasing the tarballs that way is unusual. I have never seen this before. Every package I have built through the years has world readable permissions.

This is not a bug per se, but sure is inconvenient. The problem is tarballs only, not my local GIT tree. I'll add this item to the etherpad check list. :)

Raising to BLOCKER as R14.0 should have this issue fixed.  This will require a simple update of the release generation scripts.

Could this report be closed as resolved? We have the problem itemized in our etherpad pre-release check list.

Looks like this slipped through the hoops with 3.5.13.1. File permissions are slavek:users rather than root:root.

I examined the current GIT tree and did not find any file or folder that should be with permissions 640 or 750. If future packages will be packaged under the user instead of the root, then this problem has not come. Is that so?

I suppose as long as all files in any tarball are world readable by any user then half the original problem disappears.

Seems to me ownership in the tarballs should be root:root, but if not they should be something like trinity:trinity or trinity:users, or something like that.

This has been fixed in the release creation scripts on the TDE servers.

Specifically, the following commands will be executed prior to each tarball being created:
chown root *
chgrp root *
chmod -R g+r,o+r *

Slavek, you should probably do the same in your SRU generation process.

For creating tarballs I now use create_tarball included in the 'scripts'. In this is the setting owner and group already solved by another way - using tar parameters: --owner=root --group=users

(In reply to comment #8)
> For creating tarballs I now use create_tarball included in the 'scripts'. In
> this is the setting owner and group already solved by another way - using tar
> parameters: --owner=root --group=users

OK.  Is the 'users' group GID guaranteed to be the same across all *NIX systems?  If not, then root should probably be used to avoid undefined behaviour on the target system.