Thank you Ryan, I can confirm that the port command will run without error with the new version of MacPorts base after the initial error report.
Regarding the default UID and GID: - The GID, as you mention, already exists on the system via virtue of a previous install of postgreSQL packages. - The UID 500 does not pre-exist. The latter might be the problem because the parent folder has the permissions of root:wheel. With there being no account with the UID of 500 existing on the system, it is not listed in wheel and so this may cause sudo to fail. > On 20 Oct 2022, at 19:41, Ryan Schmidt <[email protected]> wrote: > > 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). >
