Port py39-tensorflow-metal not found on arm64

[essandess (Steve Smith)]

Apparently #63776 is not fixed:

arch 
arm64
sudo port install py39-tensorflow-metal
Error: Port py39-tensorflow-metal not found

macOS 12.0.1 21A559 arm64
Xcode 13.1 13A1030d

[ryandesign (Ryan Carsten Schmidt)]

Hmm, the PortIndex files on the server look fine to me.

$ grep -El 'name py39-tensorflow-(macos|metal) ' PortIndex_darwin_2*/PortIndex
PortIndex_darwin_20_arm/PortIndex
PortIndex_darwin_21_arm/PortIndex

$ grep -El 'name py38-tensorflow-(macos|metal) ' PortIndex_darwin_2*/PortIndex
PortIndex_darwin_20_arm/PortIndex
PortIndex_darwin_20_i386/PortIndex
PortIndex_darwin_21_arm/PortIndex
PortIndex_darwin_21_i386/PortIndex

You are sure your ports tree is up to date and properly indexed?

Run sudo port -d selfupdate and make sure it's getting the PortIndex files from the PortIndex_darwin_21_arm rsync directory.

[essandess (Steve Smith)]

Replying to ryandesign:

Hmm, the PortIndex files on the server look fine to me.

$ grep -El 'name py39-tensorflow-(macos|metal) ' PortIndex_darwin_2*/PortIndex
PortIndex_darwin_20_arm/PortIndex
PortIndex_darwin_21_arm/PortIndex

$ grep -El 'name py38-tensorflow-(macos|metal) ' PortIndex_darwin_2*/PortIndex
PortIndex_darwin_20_arm/PortIndex
PortIndex_darwin_20_i386/PortIndex
PortIndex_darwin_21_arm/PortIndex
PortIndex_darwin_21_i386/PortIndex

You are sure your ports tree is up to date and properly indexed?

No, I am not. I do not see that directory structure at all. Here’s what I see with a find command (after selfupdate):

sudo find /opt/local/var/macports/ -type f -name PortIndex
/opt/local/var/macports//sources/rsync.macports.org/macports/release/tarballs/ports/PortIndex
/opt/local/var/macports//sources/rsync.macports.org/macports/release/tarballs/PortIndex

sudo find /opt/local/var/macports/ -type f -name PortIndex | xargs -I {} grep -El 'name py39-tensorflow-(macos|metal) ' '{}'
# no results

This is with a fresh GitHub install on Monterey from ​https://github.com/macports/macports-base/releases/tag/v2.7.1.

I presume something must be fixed somewhere.

[essandess (Steve Smith)]

The last line of my /opt/local/etc/macports/sources.conf is:

rsync://rsync.macports.org/macports/release/tarballs/ports.tar [default]

Is this correct for the M1?

[ryandesign (Ryan Carsten Schmidt)]

Yes, that rsync value is correct for all users.

The PortIndex directory structure I mentioned above exists only on the server. The MacPorts client knows your OS platform/major/arch and retrieves the corresponding index from the server, if you are syncing with rsync. I was hoping that a log of your sync or selfupdate would confirm that you are getting the correct server-side index, however looking at someone else's selfupdate log it does not appear to show the URL from which it gets the PortIndex so that won't help.

If you are syncing with git, then the index is generated locally on your machine in which case it should definitely be up to date and correct for your machine.

You could try deleting the PortIndex and syncing again.

port -v installed shows that your ports are indeed installed for arm64? I remember an issue where if you run a terminal app or shell on arm64 that is compiled for x86_64, then MacPorts thinks you are on an x86_64 machine and behaves accordingly.

[essandess (Steve Smith)]

Thank you very much—I got it working.

There may be an issue running port under the universal /bin/bash shell.

This wasn’t working on an M1:

echo $BASH
/bin/bash

file $BASH
/bin/bash: Mach-O universal binary with 2 architectures: [x86_64:\012- Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>] [arm64e (caps: 0x2):\012- Mach-O 64-bit arm64e (caps: PAC00) executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>]

This worked:

/opt/local/bin/bash

echo $BASH
/opt/local/bin/bash

file $BASH
/opt/local/bin/bash: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

sudo rm /opt/local/var/macports//sources/rsync.macports.org/macports/release/tarballs/ports/PortIndex
sudo port selfupdate

[kencu (Ken)]

appeared to be local issue