Arch Linux

Indeed someone else (solstice) reported that issue, but I'm very confused about what the actual problem is. Thanks for reporting the bug anyway, I am not sure why solstice didn't do it.

So you also seem to think this a regression from makepkg 3.1. Any chances you can try with makepkg 3.0 in the same condition?
You could grab makepkg and makepkg.conf from 3.0.6 tarball : ftp://ftp.archlinux.org/other/pacman/pacman-3.0.6.tar.gz

solstice said he didn't have this issue with 3.0.6. But I can reproduce the problem with both versions...
Now that I think about it, make sure you also build as user (with fakeroot) in 3.0.6.

When building as root, with 3.0.6 or 3.1.0, it works fine for me.

I can confirm that it's reproducible under both 3.0.6 and 3.1.0.
Changing umask to 022 before makepkg'ing works fine.
Please also note, that the Opera's install.sh script complains when run with umask set to something different than 022. Funny though that it installs fine when run from PKGBUILD's build() function.
I have no idea how comes it worked fine in the past. I don't think Opera changed something, I have installe the same version (20080103) previously (about 2 weeks ago) without any problems.

makepkg sets the umask to 022 itself. you can add the umask command to the PKGBUILD build function, to check that.
So I don't understand what is the difference between setting the umask in the shell calling makepkg, and setting it in makepkg itself.

Also note that the problem only happens when using fakeroot. There are also known bugs with fakeroot :
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361306

I am still able to reproduce the problem mentioned there, even with fakeroot 1.9 which was supposed to fix it.
And whether I am in a filesystem with ACL or not doesn't matter. I always get the permission problem.

Thing is that I tested adding the umask command to PKGBUILD and it doesn't work at all(!). If makepkg is supposed to do it, too, maybe it's blocked somehow?

Just a guess: maybe fakeroot wraps/blocks the umask changes and we need to set the umask BEFORE we use fakeroot?

well, it's not that...

Ok, thanks to Eliott and Xavier here:

Steps to reproduce
------------------
umask 077
fakeroot
umask 022
touch x y z
exit
tar czf foo.tar.gz x y z --preserve #ERROR is with --preserve
tar czf bar.tar.gz x y z
mkdir foo
mkdir bar
mv foo.tar.gz foo/
mv bar.tar.gz bar/
cd foo && tar xzf foo.tar.gz && cd ..
cd bar && tar xzf bar.tar.gz && cd ..

#check perms now
ls -l foo/
tar -tzvf foo/foo.tar.gz

ls -l bar/
tar -tzvf bar/bar.tar.gz

The issue appears to happen when EXTRACTING a tarball with --preserve

Xavier, I cannot reproduce any permission problems anymore with fakeroot 1.9. Can you create a test case and comment on bug #8214? It seems that these bugs are related.

Thomas: Ok, I added a comment there.
But I am no longer sure the two bugs are related.

Aaron: I followed your instructions, and I get the same permissions in the two archives (644 on all files inside), and the same permissions when the archive are extracted (600 on all files in foo/ and bar/).

Now, about this opera package. When I install it manually :
$ mkdir test
$ ./install.sh DESTDIR=test
$ ls -l test/usr/share/opera/encoding.bin
-rw------- 1 xav xav 653419 jan 3 12:04 test/usr/share/opera/encoding.bin

That is with umask 022, because with another umask, the install.sh script won't even run at all!
So isn't the problem only in opera install script?

I don't understand how makepkg manages to get 644 permission on all these files, when run with umask 022.
$ ls -l pkg/usr/share/opera/encoding.bin
-rw-r--r-- 1 xav xav 653419 jan 3 12:04 pkg/usr/share/opera/encoding.bin

This is driving me nuts. I just tried again the first manual step. And now I get 644 permission there too! Just crazy.

Xavier, it was driving me nuts, too, but I found out it somehow sets the umask permanently (?) for the session when I put the umask into PKGBUILD explicitly. Or something like this, not sure, it's all weird. However still, umask run from console shown umask bits like it should, fakeroot was probably setting it only for itself or what? I had to logout to bring the things back to normal.
I am just blindly guessing here, this is nothing to be sure of at all.

I am officially deeming this: Most Confusing Bug Ever

519:cromo@kromka:~$ subdownloader
python: can't open file '/usr/share/subdownloader/SubDownloader.py': [Errno 13] Permission denied

Downloaded from AUR. Same problem.

Hm, something related to fakeroot was reported in  FS#9232 

I really think this is just an opera installer problem.

This is my testing

> umask 022
> makepkg
Permissions are good

> cd src/opera.../ # using src as extracted by amkepkg
> ./install.sh DESTDIR=tmpdir
Permissions are good

Clear all {pkg,src} directories
> umask 077
> makepkg
Permissions are bad

> cd src/opera.../ # using src as extracted by makepkg
> umask 022 # Won't install otherwise
> ./install.sh DESTDIR=tmpdir
Permissions are bad

A brief ivestigation suggests that in the opera install.sh "cp" is used to install files. If they are not extracted with the right permissions...

Of course!
I checked again and it all makes sense now.
I did really well on this one. First, I managed to confuse everyone by talking about fakeroot bugs and stuff.
And when  bug 9362  was reported, I also failed to see the link with it..

So, well, we are back to the question asked in that other bug report then :
should we move (or copy) umask 022 to the beginning of makepkg?

Hm, actually, since handledeps sources profile.d/ and stuff, and the extraction happens after,
maybe we should set the umask just once right before the extraction?

Should be fixed in git (for the 3.1.2 release) :
http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=17180890a58365d717a8f79d2e60f5af4f829eef

OK, but how about setting the umask back after finishing building of package?

It isn't done automatically? I thought the umask was only set for the makepkg shell session.

Oh, I see. Didn't know that.