On Oct 20, 2022, at 10:11, Olaf Sulla wrote: > I installed the update to MacPorts 2.8.0 earlier today on a Mac Mini A1 > running Monterey 12.6. > > During the install the following error was reported: > > NFO: Syncing port data and updating port-base ... > Password: > ---> Updating MacPorts base sources using rsync > MacPorts base version 2.7.2 installed, > MacPorts base version 2.8.0 downloaded. > ---> Updating the ports tree > ---> MacPorts base is outdated, installing new version 2.8.0 > Installing new MacPorts release in /opt/local as root:wheel; permissions 0755 > > Error: Couldn't change permissions of the MacPorts sources at > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base > to root: child killed: kill signal > Please run `port -v selfupdate' for details. > Error: /opt/local/bin/port: port selfupdate failed: Couldn't change > permissions of the MacPorts sources at > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base > to root: child killed: kill signal > ERROR: Self update failed with exit code: 1 > ERROR: MacPorts sync failed > > I re-ran the self update with the ‘-v’ option but no error was reported.
We also saw these errors on our automated build system, e.g.: https://build.macports.org/builders/ports-11_x86_64-watcher/builds/24366/steps/selfupdate/logs/stdio And other users have reported the error too: https://trac.macports.org/ticket/66031 So there does appear to be some problem that we need to fix. After our automated build system encountered this error, MacPorts 2.8.0 was nevertheless installed and appeared to work normally, so you may be able to just ignore the error for now. > I checked the folder permissions: > > ls -la > /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs > total 226484 > drwxr-xr-x 10 root wheel 320 Oct 20 11:50 . > drwxr-xr-x 3 root wheel 96 Nov 29 2020 .. > -rw-r--r-- 1 root wheel 18098189 Oct 20 08:34 PortIndex > -rw-r--r-- 1 root wheel 512 Oct 20 08:56 PortIndex.rmd160 > drwxr-xr-x 30 root postgres 960 Oct 20 07:02 base > -rw-r--r-- 1 root wheel 113716224 Oct 20 07:45 base.tar > -rw-r--r-- 1 root wheel 512 Oct 20 07:45 base.tar.rmd160 > drwxr-xr-x 62 root postgres 1984 Oct 20 11:50 ports > -rw-r--r-- 1 root wheel 100087808 Oct 20 08:56 ports.tar > -rw-r--r-- 1 root wheel 512 Oct 20 08:56 ports.tar.rmd160 > > Group II: > > drwxr-xr-x 30 0 505 960 Oct 20 07:02 base > drwxr-xr-x 62 0 505 1984 Oct 20 11:50 ports > > > The ‘postgres’ group is listed via dscl. > > I was not expecting to see the group set to ‘postgres’ on these folders. > > Could you please advise if I should raise one or more tickets for this, and > could you confirm what permissions I should expect to find on these folders. The files in the base.tar and ports.tar tarballs generated by our server are currently owned by uid 500 and gid 505 because those are the uid and gid of the process that runs on the server that generates the tarballs. What those uid and gid map to on each user's system will be different, so you may see different usernames and group names for those files on each system, or you may see the numbers 500 or 505 if you do not have those uids or gids assigned. On your system, gid 505 happens to have been assigned to postgres. This situation is untidy, but has not been a problem before. Ideally, to reduce confusion, I should change the server-side process that generates the tarballs so that the files are owned by a predictable user and group, such as the macports user and group, but I haven't done that yet. This will require either running the process as the macports user (which is untidy and may be impossible due to the deliberately limited capabilities of that user), running the process as root (which I had hoped to avoid because it gives that process unlimited capabilities), or using the fakeroot program (which I think will work).
