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 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 wheel113716224 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 wheel100087808 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).
>
