x264 port cannot be parsed by MacPorts earlier than 2.11.0 because it uses git livecheck

[cgilles (HumanDynamo)]

--->  Computing dependencies for ffmpeg7
Error: Dependency 'x264' not found.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port ffmpeg7 failed
FAILED COMMAND: port install ffmpeg7 +gpl2 +nonfree

x264 port is marked as removed in the Macports web interface. Why?

[ryandesign (Ryan Carsten Schmidt)]

Presumably because x264 was changed 2 days ago to use git livecheck, and git livecheck is a new feature introduced in MacPorts 2.11.0, and presumably both you and the server running the ports.macports.org web site are using a version of MacPorts earlier than 2.11.0 and the port cannot be parsed on those old MacPorts versions. The solution is to upgrade to a newer version of MacPorts by running sudo port selfupdate.

We typically wait two weeks after a new version of MacPorts is released before adopting its features in ports. It has been over 2 weeks since MacPorts 2.11.0 was released so using the new git livecheck type in the x264 port is fair game.

[ryandesign (Ryan Carsten Schmidt)]

I filed ​https://github.com/macports/macports-webapp/issues/388 to update the ports.macports.org web site's copy of MacPorts.

[BjarneDMat]

It's not enough to upgrade to MacPorts base version 2.11.3
Due to the broken backend it't no longer present in ports.tar.gz

#=> port -d selfupdate
MacPorts base version 2.11.3 installed,
#=> port info x264
Error: Port x264 not found
#=> port -q installed x264
  x264 @0.164.3108_1 (active)

I discovered the issue during a routine port reclaim

[ryandesign (Ryan Carsten Schmidt)]

When you say "the broken backend", you are talking about something different than I thought we were talking about.

I mentioned the ports.macports.org web site.

You are talking about ports.tar.gz which is created by a different server (the buildmaster). It automatically updates its copies of MacPorts so it should not be affected.

However, I checked the buildmaster's mprsyncup log and it says the reason for the problem is:

Failed to parse file multimedia/x264/Portfile: invalid command name "livecheck.branch"

Further, I found that the copy of MacPorts used by mprsyncup is stuck at version 2.10.7. It has not auto-updated like it's supposed to.

The auto-update has failed on every MacPorts version after 2.10.7 due to this error:

2025-07-23T07:23:00+0000 chmod: /Volumes/RAID/var/tmp/mprsyncup/release/base/vendor/vendor-destroot/Volumes/RAID/var/tmp/mprsyncup/opt/local/libexec/macports/lib/critcl*: No such file or directory
2025-07-23T07:23:00+0000 make[1]: *** [.stamp-critcl] Error 1
2025-07-23T07:23:00+0000 make: *** [all] Error 1

[ryandesign (Ryan Carsten Schmidt)]

Such an error was previously reported in comment:ticket:72061:3.

[ryandesign (Ryan Carsten Schmidt)]

In 581d5c60faf1c35ebab642dbec8fa0b1bed4cedf/macports-ports (master):

x264: Restore compatibility with MacPorts < 2.11.0

Restore compatibility with MacPorts < 2.11.0 while we figure out why
the servers aren't able to update to 2.11.x.

See: #72733

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

chmod: /Volumes/RAID/var/tmp/mprsyncup/release/base/vendor/vendor-destroot/Volumes/RAID/var/tmp/mprsyncup/opt/local/libexec/macports/lib/critcl*: No such file or directory

On macOS /var is a symlink to /private/var and on the buildmaster additionally /Volumes/RAID/var is a symlink to /Volumes/RAID/private/var.

There is no /Volumes/RAID/var/tmp/mprsyncup/release/base/vendor/vendor-destroot/Volumes/RAID/var/tmp/mprsyncup/opt/local/libexec/macports/lib/critcl*

But there is /Volumes/RAID/var/tmp/mprsyncup/release/base/vendor/vendor-destroot/Volumes/RAID/private/var/tmp/mprsyncup/opt/local/libexec/macports/lib/critcl*

So someone is resolving a symlink in some cases but not in all cases.

[ryandesign (Ryan Carsten Schmidt)]

Lots of calls to [file normalize …] in source:macports-base/vendor/critcl-3.3.1/build.tcl@7bf1511f722750aed7dd9e9f1edf6c31b9674fa5​.

[ryandesign (Ryan Carsten Schmidt)]

A simple reproduction recipe is:

./configure --prefix=/tmp/mp && make -j$(sysctl -n hw.activecpu)

(since /tmp is a symlink to /private/tmp). Result:

Installed package:      /Volumes/Shared/macports-base/vendor/vendor-destroot/private/tmp/mp/libexec/macports/lib/critcl_callback_tcl8-1.1
Installed headers:      /Volumes/Shared/macports-base/vendor/vendor-destroot/private/tmp/mp/libexec/macports/include/critcl_callback
chmod: /Volumes/Shared/macports-base/vendor/vendor-destroot/tmp/mp/libexec/macports/lib/critcl*: No such file or directory
make[1]: *** [.stamp-critcl] Error 1
make: *** [all] Error 1

I suspect that we either need to make build.tcl not normalize paths, which probably involves patching, or we need to make vendor/Makefile.in normalize ${PREFIX} when referring to ${DESTROOT}${PREFIX}, however I don't know how to normalize. readlink -f, for example, does not work when the path doesn't yet exist (in BSD readlink, although it would work with GNU readlink). I guess invoking tclsh and using its [file normalize] would be the most reliable. Potentially the entire chmod command could be done in Tcl.

[jmroot (Joshua Root)]

I'll aim to get a fix in the next base release. We could also switch to the new buildmaster, which doesn't have this problem (and as a bonus, has the fix for #71755 in place).

[jmroot (Joshua Root)]

In 2a7829df70273b1ac7c1221f2ee8e9786e60fb00/macports-base (master):

Fix building with a prefix containing symlinks

See: #72733

[jmroot (Joshua Root)]

Replying to ryandesign:

Further, I found that the copy of MacPorts used by mprsyncup is stuck at version 2.10.7. It has not auto-updated like it's supposed to.

The auto-update has failed on every MacPorts version after 2.10.7 due to this error:

Was it able to update to 2.11.4?

[ryandesign (Ryan Carsten Schmidt)]

Yes! I'll revert the livecheck change to x264.

[ryandesign (Ryan Carsten Schmidt)]

No I won't because I don't know ​if the webapp's copy has been updated yet.

[jmroot (Joshua Root)]

The linked macports-webapp issue is closed and it looks like the x264 port is avoiding use of git livecheck when parsed by older base versions. Can this ticket be closed?

[mohd-akram (Mohamed Akram)]

Fixed in [581d5c60faf1c35ebab642dbec8fa0b1bed4cedf/macports-ports].