reinplace: could not set group for file: not owner (--with-no-root-privileges)

[jonthn+macports@…]

Trying to install perl5.8 I got this error, probably related to #20887

This time I as using MacPorts trunk. Configured like this :

./configure --prefix=$HOME/pristine/ --with-no-root-privileges --with-universal-archs="x86_64 i386"

--->  MacPorts base is probably trunk or a release candidate

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated
MacPorts running without privileges. You may be unable to complete certain actions (e.g. install).
--->  Computing dependencies for perl5.8.
MacPorts running without privileges. You may be unable to complete certain actions (e.g. install).
--->  Fetching perl5.8
--->  perl-5.8.9.tar.bz2 doesn't seem to exist in /Users/build/pristine/var/macports/distfiles/perl5.8
--->  Attempting to fetch perl-5.8.9.tar.bz2 from http://arn.se.distfiles.macports.org/perl5.8
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10.6M  100 10.6M    0     0   764k      0  0:00:14  0:00:14 --:--:--  813k
MacPorts running without privileges. You may be unable to complete certain actions (e.g. install).
--->  Verifying checksum(s) for perl5.8
--->  Checksumming perl-5.8.9.tar.bz2
MacPorts running without privileges. You may be unable to complete certain actions (e.g. install).
--->  Extracting perl5.8
--->  Extracting perl-5.8.9.tar.bz2
MacPorts running without privileges. You may be unable to complete certain actions (e.g. install).
--->  Applying patches to perl5.8
--->  Applying /Users/build/pristine/var/macports/sources/rsync.macports.org/release/ports/lang/perl5.8/files/patch-perl.c.diff
patching file perl.c
--->  Applying /Users/build/pristine/var/macports/sources/rsync.macports.org/release/ports/lang/perl5.8/files/patch-Configure.diff
patching file Configure
Error: Target org.macports.patch returned: could not set attributes of "/Users/build/pristine/var/macports/build/_Volumes_medium_jonthn_pristine_var_macports_sources_rsync.macports.org_release_ports_lang_perl5.8/work/perl-5.8.9/Configure": permission denied
Warning: the following items did not execute (for perl5.8): org.macports.activate org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install
Error: Status 1 encountered during processing.

[ricci@…]

Does this happen only for perl 5.8? If its other ports as well, most likely a base/ problem like the related ticket you pointed out (#20887).

[jonthn+macports@…]

After applying the patch I wrote in ticket #20887 other ports work (for the few that I needed/tested) but Perl5.8 fail like seen above.

Most likely a base/ problem like you said except I couldn't find where or why "port" try to modify file attributes during the patching phase. So I'm unsure and reported this problem.

[jonthn+macports@…]

Okay after a break and searching again for the problem I found it. And made a patch. In fact the problem was simple. The unpacked source tree of Perl doesn't give write right to the 2 file to be patched.

So in a pre-patch I give those rights and patching works and the build goes on. It would probably be better to verify the rights of the file to be patched in some internal function of the patch phase of MacPorts.

Hope it's good

[ryandesign@…]

Your patch is for perl5.8 but this is a base problem so we need a patch for base. I have seen the issue with mysql5, readline, cmake -- it seems to occur when trying to use reinplace on a file that has already had a patchfile applied to it, which is something that happens quite often.

This all used to work in MacPorts 1.7.1, so I would like to know what revision caused the issue to occur, so that we can more closely examine that revision and why it had that effect, see what change the revision was trying to make, and see if there is another way to achieve that without causing the problem.

[ryandesign@…]

Has duplicate #21183.

[blb@…]

I think, in part, this issue is that the files being patched are mode 0444 in the tarball itself:

...
-r-xr-xr-x  0 nick   nick   520000 Oct 30  2008 perl-5.8.9/Configure
-r--r--r--  0 nick   nick   212259 Oct 23  2008 perl-5.8.9/configure.com
-r-xr-xr-x  0 nick   nick     2615 Sep  4  2003 perl-5.8.9/configure.gnu
...

I'm pretty sure I had perl5.8 installed with MacPorts trunk on 10.5 (non-root) not too long ago, so this may perhaps be a tightening in 10.6?

The simplest fix is for base to simply chmod u+w all of ${worksrcpath}, but would that bring on other issues? Anything needing tight permissions should probably be setting them during destroot.

[ryandesign@…]

Replying to blb@…:

I think, in part, this issue is that the files being patched are mode 0444 in the tarball itself.

That's not it. The file permissions are fine (in the below case 0644) after extract, but go bad (0600) during patch. Here's results for readline, but I've seen the same with other ports as noted above.

$ port extract readline
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
--->  Computing dependencies for readline
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
--->  Fetching readline
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
--->  Verifying checksum(s) for readline
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
--->  Extracting readline
$ ls -l /mp/var/macports/build/_Volumes_data_macports_ports_devel_readline/work/readline-6.0/support/shobj-conf
-rw-r--r--   1 rschmidt  rschmidt  13886 Jan  4  2009 /mp/var/macports/build/_Volumes_data_macports_ports_devel_readline/work/readline-6.0/support/shobj-conf
$ port patch readline
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
--->  Computing dependencies for readline
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
MacPorts running without privileges. You may be unable to complete certain actions (eg install).
--->  Applying patches to readline
Error: Target org.macports.patch returned: could not set group for file "/mp/var/macports/build/_Volumes_data_macports_ports_devel_readline/work/readline-6.0/support/shobj-conf": not owner
Error: Status 1 encountered during processing.
$ ls -l /mp/var/macports/build/_Volumes_data_macports_ports_devel_readline/work/readline-6.0/support/shobj-conf
-rw-------   1 rschmidt  rschmidt  13997 Sep 23 21:23 /mp/var/macports/build/_Volumes_data_macports_ports_devel_readline/work/readline-6.0/support/shobj-conf
$

It's something about the combination of patching followed by reinplacing; the problem goes away if I remove either the patchfile or the reinplace.

I'm pretty sure I had perl5.8 installed with MacPorts trunk on 10.5 (non-root) not too long ago, so this may perhaps be a tightening in 10.6?

I have tested the release_1_8 branch @58126 on all five OS/arch combinations and I experience the problem on 10.4 and 10.5 but not on 10.6.

[ryandesign@…]

Replying to ryandesign@…:

This all used to work in MacPorts 1.7.1, so I would like to know what revision caused the issue to occur, so that we can more closely examine that revision and why it had that effect, see what change the revision was trying to make, and see if there is another way to achieve that without causing the problem.

I have tracked the problem to r45851, specifically where it changed "exec cp" to "file copy -force" in the reinplace proc in portutil.tcl. Reverting that change fixes the problem, but of course this was changed in the first place because we wanted to avoid using shell utilities (which might not be the ones we think they are) and move to using tcl commands where possible. So why does "file copy -force" behave differently from "exec cp" in this case, and is there a way to make it behave the way we want?

[jmr@…]

1.8.1 milestone is closing, moving open tickets out

[raphael@…]

Cc Me!

[jmr@…]

I see that cp applies the current umask when creating the new file, but file copy does not. So I'm wondering whether this is affected by the fix for #21389. It also seems like fileAttrsAsRoot shouldn't be trying to set the owner or group when not running as root, since in general that will not work.

[ryandesign@…]

I have been wondering whether we should be using the MacPorts copy alias instead of the tcl file copy directly, so that if file copy has bugs, we can fix them in copy.

[jmr@…]

Changed fileAttrsAsRoot to change only permissions when not running as root in r59597.

[jmr@…]

Fix confirmed  on the list. Merged to branch in r61583.