Arch Linux

Isn't this the point of 444 permissions? Why did you mark the files non-writable in the first place? All tools if not run as root should fail on writing non-writable files. (yes, even if the owner could simply chagne this using chmod).

So, there is no bug in strip but your file permissons are wrong. Change them to 755 or 644.

Search your filesystem in /lib and /usr for 444 and 555 - there must be many packages wrong then.

At least I could build and strip my OpenOffice packages until short before Christmas. Afaik this was right before new toolchain moved to core. So I think it should be toolchain bump or kernel .32 related.

It is caused by makepkg and fakeroot usage it seems:

without fakeroot some tesfiles look ok when using install -Dm444/555/644/755 command inside a PKGBUILD:
[andyrtr@laptop64 trunk]$ ls -lha pkg/
insgesamt 24K
drwxr-xr-x 2 andyrtr users 232 30. Dez 15:25 .
drwxr-xr-x 5 andyrtr users 456 30. Dez 15:25 ..
-rw-r--r-- 1 andyrtr users 187 30. Dez 15:25 .CHANGELOG
-rw-r--r-- 1 andyrtr users 509 30. Dez 15:25 .PKGINFO
-r--r--r-- 1 andyrtr users 224 30. Dez 15:25 sysctl.conf444
-r-xr-xr-x 1 andyrtr users 224 30. Dez 15:25 sysctl.conf555
-rw-r--r-- 1 andyrtr users 224 30. Dez 15:25 sysctl.conf644
-rwxr-xr-x 1 andyrtr users 224 30. Dez 15:25 sysctl.conf755
[andyrtr@laptop64 trunk]$ tar -tvf /home/andyrtr/nfs/arch64/packages/procps-3.2.8-6-x86_64.pkg.tar.gz
-rw-r--r-- andyrtr/users 509 2009-12-30 15:25 .PKGINFO
-rw-r--r-- andyrtr/users 187 2009-12-30 15:25 .CHANGELOG
-r--r--r-- andyrtr/users 224 2009-12-30 15:25 sysctl.conf444
-r-xr-xr-x andyrtr/users 224 2009-12-30 15:25 sysctl.conf555
-rw-r--r-- andyrtr/users 224 2009-12-30 15:25 sysctl.conf644
-rwxr-xr-x andyrtr/users 224 2009-12-30 15:25 sysctl.conf755

with fakeroot used:
[andyrtr@laptop64 trunk]$ ls -lha pkg/
insgesamt 24K
drwxr-xr-x 2 andyrtr users 232 30. Dez 15:23 .
drwxr-xr-x 5 andyrtr users 408 30. Dez 15:23 ..
-rw-r--r-- 1 andyrtr users 187 30. Dez 15:23 .CHANGELOG
-rw-r--r-- 1 andyrtr users 541 30. Dez 15:23 .PKGINFO
-rw-r--r-- 1 andyrtr users 224 30. Dez 15:23 sysctl.conf444
-rwxr-xr-x 1 andyrtr users 224 30. Dez 15:23 sysctl.conf555
-rw-r--r-- 1 andyrtr users 224 30. Dez 15:23 sysctl.conf644
-rwxr-xr-x 1 andyrtr users 224 30. Dez 15:23 sysctl.conf755
[andyrtr@laptop64 trunk]$ tar -tvf /home/andyrtr/nfs/arch64/packages/procps-3.2.8-5-x86_64.pkg.tar.gz
-rw-r--r-- root/root 541 2009-12-30 15:23 .PKGINFO
-rw-r--r-- root/root 187 2009-12-30 15:23 .CHANGELOG
-r--r--r-- root/root 224 2009-12-30 15:23 sysctl.conf444
-r-xr-xr-x root/root 224 2009-12-30 15:23 sysctl.conf555
-rw-r--r-- root/root 224 2009-12-30 15:23 sysctl.conf644
-rwxr-xr-x root/root 224 2009-12-30 15:23 sysctl.conf755

So is this a fakeroot bug or do we leave the fakeroot environment to late in makepkg?

I'm confused; what issue are you pointing out in your last comment? I don't see the differences between the two ls outputs outside of the owners of the files.

With fakeroot the file in pkg dir is 644 instead of 444 -rw-r--r-- 1 andyrtr users 224 30. Dez 15:23 sysctl.conf444 - the other was round would make sense why strip is failing.

I wonder where strip is failing over 444/555 that it didn't in the past. Can we also run into http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534879 or one of the other open fakeroot bugs?

Can you try updating fakeroot (1.14.4) to see if that helps?

@Andy: is the package having correct permissions in the tarball but not the /pkg dir correct? Or did you copy and paste wrong?

So... it looks like we have a combination of two "bugs" here.

1) strip does not work on files with 444/555 permissions. This is not a bug in itself. If you do not have write permissions on a file then you should not be able to strip it. I guess an update (coreutils/toolchain/kernel?) fixed that bug. However, the fact makepkg tries to strip files with incompatible permissions is a bug and will cause makepkg to error out in 3.4 (set -e) so must be fixed.

2) fakeroot permission issues. This is the weirdest fscking bug ever! This can be replicated installing a file with 444 or 555 permissions under fakeroot. On exiting fakeroot, these files will end up with 644 or 755 permissions respectively. However, while within fakeroot, they will have the correct permissions. Hence a package will have files with correct permissions (unless -R is used on a PKGBUILD without a package() function).

Interesting....

allan@arch ~/tmp/fakeroot/pkg
> fakeroot cp -a source.file source.file2

allan@arch ~/tmp/fakeroot/pkg
> ls -l
total 0
-r--r--r-- 1 allan allan 0 Jan 26 00:25 source.file
-rw-r--r-- 1 allan allan 0 Jan 26 00:25 source.file2

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361306 - Thomas submitted a patch for this.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521178 - related?

I think my patch was merged in some way (note, this was almost two years ago and I have built packages on ACL-enabled file systems since then without the original bug). You could try to mount a file system without ACL support (build in ext3 or so mounted with the noacl,noxattr option) and see if it still fails.

Also, Andy's comments don't indicate a problem: Once you leave the fakeroot environment, no correct permissions are guaranteed anymore, they are only persistent as long as you are inside the fakeroot.

I think this is a bug caused by newer coreutils as fakeroot all the way back to 1.9 all suffer.

> Once you leave the fakeroot environment, no correct permissions are guaranteed anymore, they are only persistent as long as you are inside the fakeroot.

Interesting... I have never heard that before. Well, then this is not a fakeroot bug at all then.

If that is the case, we need a big warning for "makepkg -R" for PKGBUILDs without a package() function as they could result in packages with incorrect permissions.

What if we don't allow -R anymore without a package() function?

Hmm... I had considered that but thought you would be against it! :P

It would break expectations people have about -R, but as long as it is clarified in the man page it should be fine.

Haha, I'm just trying to think of a solution that is straightforward and it seems like the best option given the above constraints with fakeroot. Considering repackage right now doesn't completely do what it says it does, I wouldn't be against enforcing this and like you said, documenting it.

I would be fine with this. We should also promote using a separate package function which has its advantages especially when using -R.

Continuing down that path... Do we want to add a deprecation warning for PKGBUILDs without package() functions and make it an error in a few releases time?

Just as a summary for me of the patches needed to makepkg:
1) Only strip files if have write permissions
2) Only use -R with a package() functions
3) Deprecation warning for PKGBUILDs with no package() function (maybe?).

I makepkg is now in about as good a shape as possible with respect to this bug:
http://projects.archlinux.org/pacman.git/commit/?id=a4e3fd18 - only strip files that are writable
http://projects.archlinux.org/pacman.git/commit/?id=6995aed9 - deprecate repackaging without a package function