Re: missing pre-compiled packages

[Joshua Root]

Werner LEMBERG wrote:


I wonder why some pre-compiled packages are missing:

* ccache – the directory `https://packages.macports.org/ccache/`  
  is
   empty

* git – the directory `https://packages.macports.org/git/`  
  doesn't
   exist at all

If this is expected, where is it documented?


Yes, it's expected that not all ports will have binaries available. See 
.


The automated license checking doesn't have all the relevant 
information, so it errs on the side of not distributing. Port 
maintainers can add some options manually if it gets it wrong. I've done 
that for ccache now and binaries should be uploaded soon. Git is a 
considerably more difficult case to audit and it may well have a genuine 
license conflict that precludes binary distribution.


- Josh

Re: missing pre-compiled packages

[Joshua Root]

Chris Jones wrote:


Binaries aren’t available if the licenses of the port, and its dependencies, do 
not allow it.

To check if this is the case you should refer to the build logs which you can 
find from the ports site. E.g.

https://ports.macports.org/port/git

Then check the builds tab. Pick one, and then check the gather archives log

https://build.macports.org/builders/ports-12_arm64-builder/builds/61881/steps/gather-archives/logs/stdio

"git" is not distributable because its license "GPL-2" conflicts with license "GPL-3+" of 
dependency "gdbm"


That works if the logs are still available, but they get deleted after a 
while. The script that is used on the buildbot is available here: 



So you can check that out and run it locally as well. The script to 
execute is port_binary_distributable.tcl, which also requires 
distributable_lib.tcl to be present.


- Josh

Re: Unable to build XV

[Joshua Root]

If someone wanted to update the xv port to use this repo, that would 
make it compatible with jasper 3 (among other things): 



- Josh

MacPorts 2.8.0-beta1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.8.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of the major ones. You may like to focus your
testing on the new features in that list, as well as your normal usage.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 


OpenPGP_signature
Description: OpenPGP digital signature

Re: py27-pygtk

[Joshua Root]

Lukas Oberhuber wrote:


I'm trying to build gimp2.10.32 (I'm the mac maintainer). I've got a custom
Portfile, but for the life of me, I can't get gimps autotools (configure.ac)
to pick up on `py27-pygtk`.

I've set done this:

set python_framework${frameworks_dir}/Python.framework/Versions/2.7
configure.pkg_config_path
${python_framework}/lib/pkgconfig:${prefix}/lib/pkgconfig

with and without the second path.

I've tried many variants of

depends_lib-append port:pygtk-2.0.pc:py27-pygtk
with and without the .pc file and with and without directories before them.


That should be just:

depends_lib-append port:py27-pygtk

But as long as the correct port is already installed, that won't change the 
behaviour of pkg-config.


But every time on build I get

checking for pygtk-codegen-2.0... no
checking for pygtk defs... Package pygtk-2.0 was not found in the
pkg-config search path.
Perhaps you should add the directory containing `pygtk-2.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pygtk-2.0' found


Checking assumptions, try this outside of the port:

PKG_CONFIG_PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pkgconfig
 pkg-config --exists --print-errors pygtk-2.0

In general when asking for help debugging a port, it's very helpful to share 
the Portfile and logs in a gist or something.

- Josh

Re: py27-pygtk

[Joshua Root]

On 2022-10-13 03:58 , Lukas Oberhuber wrote:
Here is the Portfile: 
https://gitlab.gnome.org/Infrastructure/gimp-macos-build/-/blob/dee2dcff05491fd5cd455fe1ab4164633720339b/ports/graphics/gimp2/Portfile 


Here is a gist of the logs: 
https://gist.github.com/lukaso/806cfb5fd90d147b6328a7aa0112a490 



Hopefully you have some ideas! Thanks.


Well here's your problem:

:debug:configure Executing org.macports.configure (gimp210)
:debug:configure Environment: 
:debug:configure CC_PRINT_OPTIONS='YES'

:debug:configure 
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_lukasoberhuber_project_ports_graphics_gimp2/gimp210/work/.CC_PRINT_OPTIONS'
:debug:configure CPATH='/opt/local/include'
:debug:configure DEVELOPER_DIR='/Library/Developer/CommandLineTools'
:debug:configure LIBRARY_PATH='/opt/local/lib'
:debug:configure MACOSX_DEPLOYMENT_TARGET='11.0'
:debug:configure 
SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk'


There should be around 15 more environment variables set. Not just 
PKG_CONFIG_PATH and PYTHON but ones set by base like CC, CFLAGS and so on.


I think this is because the configure script is being run as part of the 
autoreconf command, not configure proper.


BTW, these two lines both do exactly the same thing, so you can just 
remove the second one:
configure.pkg_config_path 
${python_framework}/lib/pkgconfig:${prefix}/lib/pkgconfig
configure.env-append 
PKG_CONFIG_PATH=${python_framework}/lib/pkgconfig:${prefix}/lib/pkgconfig


And you don't need to specify ${prefix}/lib/pkgconfig in there because 
that's already in the default search paths.


- Josh

Re: python3, tabs, and Terminal

[Joshua Root]

Langer, Stephen A. (Fed) wrote:


I don’t know if I have something wrong in my settings or expectations, or if 
this is a bug.  Typing a tab in an Apple Terminal window while using any 
version of Python3 from MacPorts makes the terminal enter some kind of editing 
mode, instead of just indenting the line.  Python2 from MacPorts doesn't do 
this, and neither does Python3 from Apple, which makes me think that it's some 
kind of Python configuration issue in MacPorts.  The same thing happens when 
using iTerm2.

For example:

% python3
Python 3.8.15 (default, Oct 12 2022, 03:09:36)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>/def f(): / <--- anything typed here brings up old lines from 
other sessions, when I just want to indent
Do you see this with newer python versions? I don't see it in 3.10, 
FWIW. I remember there were some bugs with libedit support in older 
versions.


You can try installing py38-gnureadline, which will override the 
built-in readline module.


- Josh

Re: python3, tabs, and Terminal

[Joshua Root]

On 2022-10-13 08:05 , Joshua Root wrote:

Langer, Stephen A. (Fed) wrote:

I don’t know if I have something wrong in my settings or expectations, 
or if this is a bug.  Typing a tab in an Apple Terminal window while 
using any version of Python3 from MacPorts makes the terminal enter 
some kind of editing mode, instead of just indenting the line.  
Python2 from MacPorts doesn't do this, and neither does Python3 from 
Apple, which makes me think that it's some kind of Python 
configuration issue in MacPorts.  The same thing happens when using 
iTerm2.


For example:

% python3
Python 3.8.15 (default, Oct 12 2022, 03:09:36)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>/def f(): / <--- anything typed here brings up old lines 
from other sessions, when I just want to indent
Do you see this with newer python versions? I don't see it in 3.10, 
FWIW. I remember there were some bugs with libedit support in older 
versions.


You can try installing py38-gnureadline, which will override the 
built-in readline module.


- Josh



Turns out this is a feature: 
<https://docs.python.org/3/library/site.html#rlcompleter-config>


- Josh

MacPorts 2.8.0-rc1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.8.0-rc1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no show-stopping bugs are found in the next few days, this will
become the 2.8.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since beta1 are:
   * Fixed error when upgrading ports with no cxx_stdlib information in 
the registry.

   * Ensured that SQLite write-ahead logging is enabled on all systems.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 



OpenPGP_signature
Description: OpenPGP digital signature

Re: ports.tar corrupt?

[Joshua Root]

Dave Horsfall wrote:


I don't know what it is with MacPorts and me, but here's the latest
problem; when doing my weekly "port upgrade outdated" I get:

 Warning: Port cairo not found:
 Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.

Etc.

How do I fix that?


If the PortIndex is truly corrupt, a selfupdate or sync should set it 
right. But I think this might be a previously discussed issue where a 
scheduled reclaim run can happen when exiting after syncing the ports 
tree, without reloading the index. I'm not sure if a ticket was ever 
filed. If that's the case, you don't need to do anything, everything 
will be fine the next time you run port (because it loads the index anew 
when it starts).


- Josh

MacPorts 2.8.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.8.0 version has now
been released. It is available via the usual methods:

  - selfupdate if you already have MacPorts installed
  - package installers [1] for macOS 12 Monterey and all older releases
back to Mac OS X 10.4 Tiger  (universal arm64/x86_64 for macOS 11+,
i386/x86_64 for 10.6, i386/ppc for 10.4 and 10.5, and the rest
x86_64)
  - source tarballs, both .tar.bz2 [2] and .tar.gz [3]
  - git tag [4]

The list of what's new in 2.8.0 can be found in the ChangeLog [5].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.8.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [6].

- Josh

[1] 
[2] 

[3] 


[4] 
[5] 
[6] 

PS, my PGP key ID is 0x01FF673FB4AAE6CD,
fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD



OpenPGP_signature
Description: OpenPGP digital signature

Re: Recommendation for installing Python modules: pip or Macports

[Joshua Root]

Tom Gederberg wrote:

It appears that you can either install Python modules (py310-matplotlib, 
py310-numpy, etc) either directly from MacPorts or you can install pip (for 
example py30-pip) with MacPorts and then use pip to install the modules.

Is there a recommendation on which way to go?


There are a couple of important points here.

1. Don't use pip (or anything else) to install python modules into the same 
prefix that MacPorts uses. MacPorts won't know about them and you will get file 
conflicts. You can use the --user option to install into your home directory, 
or as has already been mentioned, the more scalable approach is to use 
virtualenv/venv and install whatever you want inside the isolated container.

2. MacPorts doesn't have all the modules on PyPI by a long shot. The modules 
that are provided as ports are usually there because either they depend on some 
non-python-module thing that is in MacPorts (and usually pip won't be able to 
install such dependencies), or something else in MacPorts depends on them.

So it depends what you're doing. You can combine the two to some extent by 
using e.g. virtualenv's --system-site-packages option.

- Josh

Re: Unable to install xz

[Joshua Root]

Kenneth Wolcott wrote:


Killed by signal: 9
Error: Failed to extract xz: command execution failed

Happens with many of the ports.

What is wrong with my system?


This seems to only happen on Ventura and only when using trace mode. 
There's a ticket open in Trac, but I don't think anyone has been able to 
analyse what's happening yet.


The workaround in the meantime is of course to not use trace mode.

- Josh

Re: Unable to install xz

[Joshua Root]

If it fails in exactly the same way without trace mode, i.e. during the 
extract phase with the message "Killed by signal: 9", please add your 
terminal transcript and corresponding log to 
<https://trac.macports.org/ticket/66358>.


- Josh

On 2022-12-10 05:40 , Kenneth Wolcott wrote:

HI Josua;

   It fails without "-t" as well.

Thanks,
Ken

On Fri, Dec 9, 2022 at 3:59 AM Joshua Root  wrote:


Kenneth Wolcott wrote:


Killed by signal: 9
Error: Failed to extract xz: command execution failed

Happens with many of the ports.

What is wrong with my system?


This seems to only happen on Ventura and only when using trace mode.
There's a ticket open in Trac, but I don't think anyone has been able to
analyse what's happening yet.

The workaround in the meantime is of course to not use trace mode.

- Josh

Re: Unable to install xz

[Joshua Root]

Sounds like the failed attempt in trace mode left the work dir in a bad 
state which was cleared up by cleaning it. There's a reason our 
troubleshooting advice usually starts with 'port clean ...'. :)


I guess now that it has succeeded and the logs are cleaned away, the 
record of exactly how it failed in between is gone.


- Josh

On 2022-12-10 13:42 , Kenneth Wolcott wrote:

Hi Joshua;

   Well, I slightly mis-spoke.  Using verbose without trace, xz install
still fails but does not have an explicit error code.

   Wow, I deleted the contents of the xz work directory and tried to
install again, now it works with verbose mode enabled but disabled
trace mode.

   I'm quite confused.

Thanks,
Ken Wolcott

On Fri, Dec 9, 2022 at 6:24 PM Joshua Root  wrote:


If it fails in exactly the same way without trace mode, i.e. during the
extract phase with the message "Killed by signal: 9", please add your
terminal transcript and corresponding log to
<https://trac.macports.org/ticket/66358>.

- Josh

On 2022-12-10 05:40 , Kenneth Wolcott wrote:

HI Josua;

It fails without "-t" as well.

Thanks,
Ken

On Fri, Dec 9, 2022 at 3:59 AM Joshua Root  wrote:


Kenneth Wolcott wrote:


Killed by signal: 9
Error: Failed to extract xz: command execution failed

Happens with many of the ports.

What is wrong with my system?


This seems to only happen on Ventura and only when using trace mode.
There's a ticket open in Trac, but I don't think anyone has been able to
analyse what's happening yet.

The workaround in the meantime is of course to not use trace mode.

- Josh

Re: Unable to install xz

[Joshua Root]

On 2022-12-10 15:03 , Kenneth Wolcott wrote:

Is the correct takeaway from this is not to use the trace flag with
the port commands for now on MacOS Ventura?


Until there's a fix for this issue, yes.

- Josh

Re: How to clean up failed build with lots of dependencies?

[Joshua Root]

Does MacPorts have a way to uninstall the dependencies it installed in 
attempting to build NetSurf (or any complex port that fails to build) without 
uninstalling the dependencies that were already installed?

Will "port reclaim" catch these?


Yes, port reclaim will clean up such ports for you. You can also use an 
expression like 'leaves and rdepof:NetSurf' to do it manually; I would 
pass it to 'port echo' first to check that it doesn't match anything you 
want to keep, and then use it with clean and uninstall.


- Josh

Re: How to clean up failed build with lots of dependencies?

[Joshua Root]

dbus[2197]: Dynamic session lookup supported but failed: launchd did not 
provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
That is provided by dbus, which should be somewhere in the recursive 
dependencies of gtk3 I think?


- Josh

Re: Finding dependents

[Joshua Root]

Postfix *with no variants* has no dependencies. That's what you will be 
shown if you run simply 'port deps postfix', because of course you have 
not specified any variants (and no variants are on by default).


I think what's wanted here is:

port deps postfix and installed

Or if you're more interested in what is installed that depends on pcre:

port dependents pcre

- Josh

chilli.namesake wrote:


postfix has no dependencies btw

>/On Dec 23, 2022, at 08:36, chilli.namesake at gmail.com 
 wrote: />//>/ />/port rdeps postfix />//>/shows it's dependencies. Probably want to pipe into more. />//>/But to see what depends on postfix, it's a little different. />//>/port echo depends:postfix />//>>>/On Dec 23, 2022, at 07:49, Gerben Wierda via macports-users 
> wrote: />>>//>>/Ik keep struggling when I try to find out dependencies once in a while. />>//>>/Suppose I have this installed: />>//>>/postfix @3.7.2_0+dovecot_sasl+pcre+smtputf8+tls (active) />>//>>/How do I find out the port dependencies with the port command such 
that port tells me my postfix depends on port:pcre?/

Re: list of packages that are always compiled

[Joshua Root]

Werner LEMBERG wrote:


Folks,


is there an option to `port` that shows me the names of all packages
that must be built from source, and which are not available
pre-compiled from 'packages.macports.org'?  Or maybe this list is
somewhere else, ideally also giving a reason?  [My use-case is
'ghostscript', for which I can't see why it is not provided
pre-compiled.]

Right now, I check 'packages.macports.org' directly whether there is a
directory, but this is inefficient IMHO – and it doesn't give the
reason :-)


There is no option to port(1) that will show this. The buildbot logs 
(which are linked from ports.macports.org) do contain this information; 
for example,  links to 
 
which in the stdio for the "gather archives" step says: "libewf" is not 
distributable because its dependency "macfuse" has license "restrictive" 
which is not known to be distributable.


Of course that's a bit more digging than would be ideal, and the logs do 
eventually get deleted, so getting the web app to remember and display 
this information right on the port details page would be a good improvement.


Also, whether a binary archive is currently available for a port and 
whether one would be made available if the port were built are two 
different questions. Answering the former requires a http request to 
packages.macports.org. To answer the latter, you can use the same script 
that the buildbot uses: 



Generating this information for all ports is not too difficult with a 
little scripting, but does take quite some time.


List which ports do and don't have an archive available (for your 
current OS version and arch): 



List which ports are and aren't considered distributable: 



- Josh

Re: list of packages that are always compiled

[Joshua Root]

Richard L. Hamilton wrote:


A plausible test case with the first of those (ffmpeg +nonfree) gave the 
expected result: return code 1, i.e. non-redistributable; and without the 
+nonfree variant, also gave the expected result of return code 0 
(redistributable). That nicely shows that the results reflect the effects of 
dependency differences based on variant.
I should also point out for those who are unfamilar with it that 
port_binary_distributable.tcl has a -v option that will show the reason 
for non-distributability (technically only the first reason it finds; 
there can be multiple reasons):


./port_binary_distributable.tcl -v ffmpeg +gpl3
"ffmpeg" is not distributable because its license "GPL-3+" conflicts 
with license "GPL-2" of dependency "libvidstab"



Does the behavior of those take into account configuration like a modified 
variants.conf (so the result aligns with what variants would be used if one did 
a port install)?
The two gists make no attempt to set any variants on the ports, so they 
will give results that apply only for the default variants. As you 
discovered, port_binary_distributable.tcl does apply variants given on 
the command line, but it doesn't have code to merge in the 
global_variations (as the variants requested via variants.conf are 
called). It would be possible to add this for all of the scripts with a 
little work.



although both of the scripts that obtain the information for all ports are 
quite slow;
Yes, which is why storing the decision made by the buildbot is 
preferable to generating the information on demand. The 
all_distributable.tcl 
 
script is doing more work than it would take to regenerate the PortIndex 
from scratch, and the latter takes well over 20 minutes on my machine. 
On the other hand, all_bin_available.tcl 
 is 
limited mainly by how fast the packages server responds, so changing it 
to use a mirror that is closer to you could help. A faster multithreaded 
implementation is left as an exercise for the reader. :-)


- Josh

Re: Error: Failed to fetch rust: The requested URL returned error: 404

[Joshua Root]

Marcus Calhoun-Lopez wrote:


For reasons that are not entirely clear, the Rust distfiles are not being 
mirrored.
See https://trac.macports.org/ticket/60511

As a workaround, you can download them yourself from 
https://github.com/MarcusCalhoun-Lopez/rust/releases/tag/1.66.0 and put them in 
/opt/local/var/macports/distfiles/rust.

-Marcus

> On Dec 27, 2022, at 10:33 PM, chilli.namesake at gmail.com wrote:
> 
> rust 404 is holding up my upgrades of 
> gd22.3.3_1 < 2.3.3_2 
> ImageMagick6.9.11-60_3 < 6.9.11-60_4   
> rav1e  0.5.1_1 < 0.5.1_2
>  
> but only on Mountain Lion. On Mojave these upgraded yesterday, and I ran the upgrades simultaneously. Why would rust be available for Mojave but 404 on Mountain Lion?


This is now fixed. BTW, the correct ticket number is 
.


- Josh

Re: Error: Failed to fetch rust: The requested URL returned error: 404

[Joshua Root]

On 2022-12-30 04:58 , mcalh...@macports.org wrote:

Please forgive my ignorance, but I am not sure how `variant mirror_i386` works.
It exists but is *not* default, so how would it be set by the mirroring 
mechanish?
If it is not set, how will `if {[variant_exists mirror_i386] && [variant_isset 
mirror_i386]} {` ever run?


It's a hack for sure. The mirroring script mirrors ports with each of 
their variants set, so that files only used by certain variants will be 
mirrored. In this case, the files are (on i386) also used for reasons 
other than the variant being set, so end users don't have to actually 
use the variant to benefit from its files being mirrored.


- Josh

Re: Error: Failed to fetch rust: The requested URL returned error: 404

[Joshua Root]

Mirroring is done for each variant and each platform, but not every 
combination of variants or of variants and platforms, due to the 
combinatorial explosion that would entail. Only the files needed by 
+universal on the machine doing the mirroring are mirrored.


- Josh

On 2022-12-31 02:47 , mcalh...@macports.org wrote:

Thank you for the explanation.
Perhaps this is a question better suited to the development mailing list, but 
why doesn’t the `universal` variant (which exists) achieve the same goal as the 
`mirror_i386` variant?

-Marcus


On Dec 29, 2022, at 7:43 PM, Joshua Root  wrote:

On 2022-12-30 04:58 , mcalh...@macports.org wrote:

Please forgive my ignorance, but I am not sure how `variant mirror_i386` works.
It exists but is *not* default, so how would it be set by the mirroring 
mechanish?
If it is not set, how will `if {[variant_exists mirror_i386] && [variant_isset 
mirror_i386]} {` ever run?


It's a hack for sure. The mirroring script mirrors ports with each of their 
variants set, so that files only used by certain variants will be mirrored. In 
this case, the files are (on i386) also used for reasons other than the variant 
being set, so end users don't have to actually use the variant to benefit from 
its files being mirrored.

- Josh

Re: PortIndex file corrupt?

[Joshua Root]

See 
.


- Josh


Today, while doing a port update, I did a port reclaim and received the 
followed errors (just a subset of the errors are listed).  What could cause 
this and how could I fix it?

You haven't run 'sudo port reclaim' in two weeks. It's recommended you run this 
regularly to reclaim disk space. Would you like to run it now? [Y/n]: Y
--->  Checking for unnecessary unrequested ports
Found no unrequested ports without requested dependents.
--->  Checking for inactive ports
Inactive ports found:
  sqlite3  @3.40.0_0
  ncurses  @6.3_0
Would you like to uninstall them? [Y/n]: Y
--->  Uninstalling sqlite3 @3.40.0_0
--->  Uninstalling ncurses @6.3_0
--->  Building list of distfiles still in use
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port cctools not found: expected non-negative integer but got "create and 
view interactive cheatsheets on the command-line"
 while executing
"read $fd $len"
 ("macports_try" body line 6)
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port bzip2 not found: expected non-negative integer but got "homepage"
 while executing
"read $fd $len"
 ("macports_try" body line 6)
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port libiconv not found: expected non-negative integer but got ""

Re: PortIndex file corrupt?

[Joshua Root]

That's the thing - the bug only affects reclaim when it runs 
automatically as part of the same command as sync or selfupdate. Your 
PortIndex was never actually corrupt on disk, it just isn't reloaded 
correctly in that specific situation.


- Josh

On 2023-1-23 09:22 , Thomas Gederberg wrote:

Thanks.  Actually I got the message a few weeks ago after doing a port 
selfupdate and it repeated again today after doing another port selfupdate so 
it appears that the second port selfupdate did not clear it.  However, I just 
tried doing a sudo port reclaim and did not get any errors.

Tom


On Jan 22, 2023, at 1:12 PM, Joshua Root  wrote:

See 
<https://lists.macports.org/pipermail/macports-users/2022-October/051512.html>.

- Josh


Today, while doing a port update, I did a port reclaim and received the 
followed errors (just a subset of the errors are listed).  What could cause 
this and how could I fix it?

You haven't run 'sudo port reclaim' in two weeks. It's recommended you run this 
regularly to reclaim disk space. Would you like to run it now? [Y/n]: Y
--->  Checking for unnecessary unrequested ports
Found no unrequested ports without requested dependents.
--->  Checking for inactive ports
Inactive ports found:
  sqlite3  @3.40.0_0
  ncurses  @6.3_0
Would you like to uninstall them? [Y/n]: Y
--->  Uninstalling sqlite3 @3.40.0_0
--->  Uninstalling ncurses @6.3_0
--->  Building list of distfiles still in use
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port cctools not found: expected non-negative integer but got "create and 
view interactive cheatsheets on the command-line"
 while executing
"read $fd $len"
 ("macports_try" body line 6)
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port bzip2 not found: expected non-negative integer but got "homepage"
 while executing
"read $fd $len"
 ("macports_try" body line 6)
Warning: It looks like your PortIndex file 
forrsync://rsync.macports.org/macports/release/tarballs/ports.tar  may be 
corrupt.
Warning: Port libiconv not found: expected non-negative integer but got ""

Re: Issue with installing port

[Joshua Root]

I'm trying to get pandoc to install.

The ticket for this is , FWIW.

- Josh

MacPorts 2.8.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.8.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

   sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 13 Ventura all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1] 
[2] 
[3] 
[4] 




OpenPGP_signature
Description: OpenPGP digital signature

Re: Install on Ventura 14.2

[Joshua Root]

Putting together a new machine (M2Pro Mini, Ventura 14.2) and have hit a snag 
installing MacPorts.  I’ve not installed Xcode on any of my systems for a 
number of years now, I simply install the appropriate CLI package from the 
Apple site.  In this case, I downloaded and installed v14.2.  I then downloaded 
the MacPorts install package for Ventura and started it up.  Twenty minutes 
later I’m still waiting for “Running Package Scripts …” to finish up.

Not being a MacPorts guru of any sort, I’m not sure what I should look at to 
see what’s up.  One thing I did find is that a file named .base.tar.ZqfTHz is 
slowly growing larger.  This file is in:
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs

I’m just letting it run for now, but I don’t ever recall this happening in 
other new installs.  Any ideas?
The installer's postflight script runs 'port selfupdate' in order to 
download the ports tree. It's a reasonably big file at just over 100 MB, 
so it could take a while depending on network performance between you 
and our server. It's also possible that you had to regenerate part of 
the PortIndex because the machine that updates it is currently without 
power, and that can also be a lengthy operation.


- Josh

Re: Install on Ventura 14.2

[Joshua Root]

On 3/2/2023 14:22, Ryan Schmidt wrote:

Generating the portindex from scratch takes hours, but just updating a slightly 
out-of-date portindex with the latest changes shouldn't take that long. Also, 
the slightly outdated portindex on the public rsync servers should correspond 
exactly to their slightly outdated collection of ports so no updating should be 
needed.


I was avoiding going into too much detail before, but depending on the 
exact timing of the power going out and the mirror syncing from the 
origin, it's possible that the indices for some subset of OS versions 
could be one update behind the ports tree. But I haven't checked whether 
that's actually the case.


- Josh

Re: gtk3 on Snow Leopard build failed

[Joshua Root]

...and things had gone so nicely on Snow Leopard for awhile now, until this:

:notice:build --->  Building gtk3
:debug:build Executing org.macports.build (gtk3)
:info:build --->  Building gtk3 for architecture x86_64
:debug:build setting option build.dir to 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64
:debug:build Environment:
:debug:build CC_PRINT_OPTIONS='YES'
:debug:build 
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/.CC_PRINT_OPTIONS'
:debug:build CPATH='/opt/local/include'
:debug:build CPLUS_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build C_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build DEVELOPER_DIR='/Developer'
:debug:build LIBRARY_PATH='/opt/local/lib'
:debug:build MACOSX_DEPLOYMENT_TARGET='10.6'
:debug:build 
MACPORTS_LEGACY_SUPPORT_CPPFLAGS='-isystem/opt/local/include/LegacySupport'
:debug:build MACPORTS_LEGACY_SUPPORT_ENABLED='1'
:debug:build MACPORTS_LEGACY_SUPPORT_LDFLAGS='-L/opt/local/lib 
-lMacportsLegacySupport'
:debug:build OBJCPLUS_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build OBJC_INCLUDE_PATH='/opt/local/include/LegacySupport'
:info:build Executing:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:debug:build system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:info:build ninja: error: unknown target 'CC=/opt/local/bin/clang-mp-8.0 -arch 
x86_64'
:info:build Command failed:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:info:build Exit code: 1
:error:build Failed to build gtk3: command execution failed
:debug:build Error code: NONE
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "$procedure $targetname"
:error:build See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/main.log
 for details.



Lest anyone wonder, /opt/local/bin/clang-mp-8.0 does exist.


I note this is a universal build. The CC and CC_FOR_BUILD settings are 
part of a workaround intended to get g-ir-scanner to use the right 
compiler. They were removed from the non-universal case recently, I 
would assume because passing them in as build args like that doesn't 
work with meson, as seen above (and I wonder if g-ir-scanner is now 
using the wrong compiler again as a result). But they were left in the 
universal case. This is something the port maintainer needs to sort out.




- Josh

Re: Cannot build glib2

[Joshua Root]

On Mon, 24 Apr 2023, Dave Horsfall wrote:


[ Disabling "+universal" ]

Yes, that seems to be it; thanks.  Now, is there a way to globally 
disable "universal" without cleaning every port and rebuilding with 
"-universal"?


You don't have to rebuild everything, but there's no getting around 
reinstalling all the ports that currently have +universal, if you want them to 
not be universal. They may or may not have to be built depending on binary 
availability. The command to do that would be:

sudo port upgrade --enforce-variants installed -universal

If you want to disable universal altogether in your MacPorts installation, set 
universal_archs to an empty value in macports.conf. Note that this will make it 
impossible to install some ports that don't support your configured build_arch.

- Josh

Re: Cannot build glib2

[Joshua Root]

Hi Ken,

Your can see the architecture(s) each port is built for with 'port -v 
installed'. The ones of concern on an Apple Silicon system will have 
archs='x86_64'.


- Josh

On 29/5/2023 09:55, Kenneth Wolcott wrote:

HI Josh;

   Is it possible to find out what ports that I have installed that
would fail to upgrade due to not supporting the M1 chip?  If, so what
command would I issue so that I could determine the risk involved of
doing that massive upgrade operation?

Thanks,
Ken Wolcott

On Sun, May 28, 2023 at 4:30 PM Joshua Root  wrote:


On Mon, 24 Apr 2023, Dave Horsfall wrote:


[ Disabling "+universal" ]

Yes, that seems to be it; thanks.  Now, is there a way to globally
disable "universal" without cleaning every port and rebuilding with
"-universal"?


You don't have to rebuild everything, but there's no getting around 
reinstalling all the ports that currently have +universal, if you want them to 
not be universal. They may or may not have to be built depending on binary 
availability. The command to do that would be:

sudo port upgrade --enforce-variants installed -universal

If you want to disable universal altogether in your MacPorts installation, set 
universal_archs to an empty value in macports.conf. Note that this will make it 
impossible to install some ports that don't support your configured build_arch.

- Josh

Re: gcc12 fault?

[Joshua Root]

Ken Cunningham wrote:


what you see is difficult to explain, unless the PATH changed between the two 
tests.

if

'which gcc' gives /opt/local/bin/gcc

then

gcc --version

should give exactly the same as

/opt/local/bin/gcc --version


Not necessarily. Shells cache command locations, so if 'gcc' was run 
prior to the creation of /opt/local/bin/gcc, subsequently invocations 
will continue to run the previously found gcc. Running 'hash -r' or 
starting a new shell will give you an empty cache and thus set things right.


The 'which' command doesn't know about the shell's cache state; it only 
looks at the current PATH. This is why 'type' often helps to understand 
what's going on in these situations, as Richard hinted.


- Josh

Re: gcc12 fault?

[Joshua Root]

On 2/6/2023 16:47, Ken Cunningham wrote:


You have probably already noted that which and type are both built in to the 
default zsh on Ventura and as far as I can tell from my testing here give 
identical results in every case. Both correctly predict the binary that will be 
executed in every case I tried.


Indeed, zsh is a bit special and implements both 'which' and 'type' in 
terms of its 'whence' builtin (which has a lot of options and can tell 
you pretty much anything you would ever want to know about a command's 
disposition, check it out.) You will notice /usr/bin/which can thus give 
different results to just 'which'.



What will happen when you add and remove binaries from an upstream PATH folder 
is a bit difficult to predict accurately. I won't try to summarize the findings 
only to have someone point out their idea of an exception, but it's fair to say 
that it's best to open a new shell to get predictable results.


You would want to start a new shell if you changed the startup files. 
Otherwise 'hash -r' is quite sufficient. Changing the value of PATH at 
runtime will do that automatically in modern shells, BTW.


- Josh

Re: Exa port dependencies

[Joshua Root]

The list below is the current list of build dependencies when I do a
port install of "exa +doc+git". The list seems pretty ridiculous though.
I just cloned the exa repository and did a cargo build outside macports.
None of these dependencies are required.
The vast majority of those are dependencies of pandoc, which is used by 
the exa port's doc variant. They won't be installed when installing exa 
from a binary archive. If you need to build locally and don't want all 
these deps, you can use -doc.


- Josh

Re: Exa port dependencies

[Joshua Root]

Ideally, docs that need significant extra deps could be a separate 
(sub)port.


- Josh

On 10/6/2023 05:14, Chris Jones wrote:

Hi,

I agree they should be the default, ‘by default’, but there are some ports 
which have a docs variant that drags in minimum build deps and thus having 
enable by default is probably fine. Anything though that drags in pandoc and 
the vast array of deps it needs should probably be optional…

Chris


On 9 Jun 2023, at 3:16 pm, Ken Cunningham  
wrote:

I have long thought the doc variants should never be the default.

Lots of bloat and extra deps and build errors.

But I know others feel differently.

I know I can set -doc in variants.conf, but then you’re building everything.


K


On Jun 9, 2023, at 04:01, Joshua Root  wrote:




The list below is the current list of build dependencies when I do a
port install of "exa +doc+git". The list seems pretty ridiculous though.
I just cloned the exa repository and did a cargo build outside macports.
None of these dependencies are required.

The vast majority of those are dependencies of pandoc, which is used by the exa 
port's doc variant. They won't be installed when installing exa from a binary 
archive. If you need to build locally and don't want all these deps, you can 
use -doc.

- Josh

Re: best Xcode version for Mojave?

[Joshua Root]

After updating Xcode while keeping the same OS, should one delete and reinstall 
all MacPorts packages?

No, there's no reason to do that if you have only changed the Xcode version.

- Josh

Re: selfupdate fails

[Joshua Root]

% sudo port -v selfupdate
--->  Updating MacPorts base sources using rsync
rsync: failed to connect to rsync.macports.org: Operation timed out (60)


Please see .

- Josh

Re: Timing of MacPorts Support for New macOS Versions

[Joshua Root]

I’m curious if you’ve revisited the NDA recently, since a skim of the verbiage 
makes it seem to me that discussing the new OSes should be OK, assuming we 
don’t review it or post screenshots. 
Fromhttps://developer.apple.com/support/terms/apple-developer-program-license-agreement/#ADPLA9.1:

> Further, Apple agrees that You will not be bound by the foregoing 
confidentiality terms with regard to technical information about pre-release Apple 
Software and services disclosed by Apple at WWDC (Apple’s Worldwide Developers 
Conference), except that You may not post screenshots of, write public reviews of, 
or redistribute any pre-release Apple Software, Apple Services or hardware.

IANAL and all, but this clause is fairly new and if you haven’t re-evaluated 
that policy for a while it might be worth doing so again.



That seems like a badly-written clause to me because there are at least 
two ways you can parse it, and it greatly changes the meaning. But in 
any case, I think it's important to point out that we are not attempting 
to give anyone advice about which actions do or don't violate their NDA. 
If you have an agreement with Apple, it's your responsibility to ensure 
that you are keeping your side of it.


The statements in the documentation and links to them in ticket comments 
are meant to be (a) a courtesy reminder that pre-release OS versions 
tend to be under NDA, since users sometimes forget this; and (b) a way 
to find out about project members that are permitted to see any 
information that is not allowed to be posted publicly. But again, it's 
up to the person who signed the NDA to determine which information that is.


If the docs are not making this sufficiently clear, please feel free to 
propose improvements or make PRs.


- Josh

Re: Is there anyone who has successfully migrated Macport to Sonoma?

[Joshua Root]

1)  For 1. below , should I use Xcode15 or older version?


Xcode 15 or later is required on Sonoma.


    2) Does the following procedure work? Is there anyone who has
successfully migrated Macport to Sonoma?
I haven't heard of any problems with the procedure that are specific to 
Sonoma. Individual ports may fail to build, as is always the case with 
new macOS versions. See .



   3) How long will this migration procedure take?
That depends on which ports you have installed and how fast your 
hardware is. Since there are no binaries built yet, the majority of the 
time will be spent compiling. There is information on ports.macports.org 
about how long ports took to build on our buildbot, which should give 
you a starting point; e.g. 
.



   4) I have upgraded to Sonoma OS. But why my present ports still work?


macOS is in general very backwards compatible, so existing binaries will 
usually keep working on newer OS versions (though there are exceptions). 
Unless you've hit one of the exceptions, the Migration procedure is only 
needed to avoid problems when you upgrade your ports or install new 
ones. As long as you never install or upgrade anything, you can keep 
using your ports as is (though that's not recommended long term of course.)


- Josh

Re: Is there anyone who has successfully migrated Macport to Sonoma?

[Joshua Root]

On 9/10/2023 10:34, Tao Zhang wrote:

Hi Josh,

  Thanks for your helpful comments. One more question:

    gfortran and ifort  do not work after upgrading to Sonoma. see below.
  1) Should I upgrade to the latest Xcode15 or old Xcode14 to fix this 
problem?

  2)  It is reported that Xcode15 does not work well with Macport, right?


Yes, there are unfortunately some build issues that affect Xcode 15 but 
not 14. However, as far as I'm aware, Xcode 14 doesn't work on Sonoma. 
So if you need to keep using Xcode 14, you probably also need to stay on 
Ventura.


- Josh

Re: FYI: The meld port depends on the p5.36-xml-parser port, which does not exist

[Joshua Root]

FYI: The meld port depends on the p5.36-xml-parser port, which does not exist

sudo port -v -s install meld
--->  Computing dependencies for meld
Error: Dependency 'p5.36-xml-parser' not found.
Error: Followhttps://guide.macports.org/#project.tickets  if you
believe there is a bug.
Error: Processing of port meld failed


Meld itself does not have this dependency:

% port deps meld
Full Name: meld @3.21.0_2+x11
Extract Dependencies: xz
Build Dependencies:   intltool, itstool, libxml2, py311-distro, makeicns,
  librsvg
Library Dependencies: desktop-file-utils, glib2, gtk3, gtksourceview4,
  py311-cairo, py311-gobject3, shared-mime-info, 
python311

Runtime Dependencies: adwaita-icon-theme, gsettings-desktop-schemas, yelp

So it must be one of its dependencies. But on my machine there is no 
such dependency:


% port rdeps meld | grep -F p5.36-xml-parser
%

So it must be something that is changing dynamically, perhaps based on 
variants.


% port echo depends:xml-parser and rdepof:meld
intltool
pulseaudio

Looking at the portfiles for these two, intltool sets a fixed 
perl5.major, but pulseaudio does not. The perl5 portgroup has something 
of a misfeature where it sets the default perl to use based on the 
currently active variant of the perl5 port. So I guess you have 
perl5+perl5_36 installed.


Please file a ticket. The pulseaudio port may not even need the 
p5-xml-parser dependency (many ports that use intltool once added this 
as a poor workaround for an old bug). But if it does, or if it records 
the path to perl at build time and then uses it at runtime, it needs to 
set a fixed perl5.major.


- Josh

Re: Help with zef Portfile

[Joshua Root]

raf wrote:


The destroot part looks like this:

   destroot {
   "${prefix}/bin/rakudo" -I"${worksrcpath}" bin/zef \
   --to="inst#${destroot}${prefix}/share/perl6/site" \
   install "${worksrcpath}"

   ln -s "${prefix}/share/perl6/site/bin/zef"   "${prefix}/bin/zef"
   ln -s "${prefix}/share/perl6/site/bin/zef-m" "${prefix}/bin/zef-m"
   }

Which results in this error:

   :error:destroot Failed to destroot raku-zef: invalid command name 
"/opt/local/bin/rakudo"
   :debug:destroot Error code: NONE
   :debug:destroot Backtrace: invalid command name "/opt/local/bin/rakudo"
   :debug:destroot while executing
   :debug:destroot "$procedure $targetname"

As "${prefix}/bin/rakudo" is valid in test.cmd,
why isn't it valid during destroot?
And how do I help destroot find it?


This is really a macports-dev question, so cross-posting this there.

When you override (e.g. destroot { ... }) or augment (e.g. post-build { 
... }) a port phase, the code you provide is executed in the Tcl 
interpreter. '${prefix}/bin/rakudo' is indeed not a valid Tcl command. 
It happens that we do define an 'ln' Tcl command that takes args very 
much like ln(1). If you want to execute something in the shell, you have 
to use the 'system' command (or sometimes 'exec' if you want to capture 
the output.)


The default destroot phase builds a string to pass to 'system' by 
combining destroot.cmd, destroot.args, etc. In this case, it might be 
easiest to use those for the rakudo command, and create the symlinks in 
a post-destroot block?


- Josh

Re: Help with zef Portfile

[Joshua Root]

raf wrote:


I tried just putting "system" before the command but it didn't work.
I couldn't find the documentation for tcl's system,


System isn't a standard Tcl thing, it's provided by MacPorts. It's 
closely analogous to system(3). It takes a single string which is passed 
to 'sh -c'.


It's documented in the portfile man page at least. If it's missing 
elsewhere, that's one more thing for the list of documentation 
improvements that are needed.



   :info:destroot Failed to create directory 
'/opt/local/share/perl6/site/short' with mode '0o777': Failed to mkdir: 
Operation not permitted
That path is outside the work path, so it's not permitted to write to it 
except in the activate phase, but apparently something in the port is 
trying to create it during the destroot phase.


- Josh

Re: Portfile magic / xinstall usage / defect?

[Joshua Root]

The brotli 
Portfile:https://github.com/macports/macports-ports/blob/master/archivers/brotli/Portfile
Contains:
   post-destroot {
  xinstall -m 640 {*}[glob ${worksrcpath}/docs/*.1] 
${destroot}${prefix}/share/man/man1/
…
   }

However, after port installation, I look in the work directory and see:
   ls -la destroot/opt/local/share/man/man1
  -r--r--r--  root  admin  …  brotli.1.gz

Also, /opt/local/share/man/man1/brotli.1.gz contains the same perms and .ext 
(as the above work/destroot).

* How is the permissions mode 444, instead of 640 (as designated in the 
post-destroot block)?
* And how did it get the .gz extension?


If you look in the log file for the brotli build after running e.g. 
'sudo port destroot brotli', you'll see a line saying "Compressing man 
pages for brotli". That comes from this code (which runs after all 
Portfile-defined destroot code): 



- Josh

Re: Portfile magic / xinstall usage / defect?

[Joshua Root]

(Moving to macports-dev)

Frank Stock wrote:


My main focus is .pkg component installers targeting systems where a 
development toolchain is not realistic.

* Do you think it would be possible to use mtree and add_users data to generate 
code for a postinstall script handling user/group creation and file ownership?

* If so, would there be any interest from the MacPorts team in a pull request 
for that?


So it sounds like you're saying that file ownership is not currently 
preserved by 'port pkg'? :)


Yes, a reasonable PR to fix that would most likely be accepted. However 
I don't think a postinstall script would be required, I'm pretty sure it 
would just be a config option for pkgbuild or something.


- Josh

Re: Idiomatic process for handling needed external language modules for which there is no port

[Joshua Root]

How do you do package management on MacPorts for languages which might
need modules which MacPorts doesn't have?

   This problem exists for many languages supported by MacPorts; ie:
Perl, Python, Raku, Julia, etc


The answer is different for each language. For Python, standard 
procedure is to use venv. 


I would assume for perl that if there isn't an equivalent mechanism, 
cpan should at least have an option to choose a different installation 
prefix. I don't know what the situation is for Raku and Julia.


- Josh

Re: How to download builds from macports?

[Joshua Root]

Be aware that not all ports are available as binary archives, and some 
ports rely on post-activate code in the Portfile being run in order to 
work properly.


- Josh

PavelTurk wrote:


Hi Dave,

Thank you very much for your answer.

Best regards, Pavel

On 12/26/23 5:19 PM, Dave Allured - NOAA Affiliate wrote:
>/Use one of the several mirror sites for pre-built binary 
distributions.  Look under section "Archives" here: />/https://trac.macports.org/wiki/Mirrors 
 />//>/Because each home page is huge, I find it convenient to postfix the 
package name for use in a browser, e.g.: />/http://atl.us.packages.macports.org/ffmpeg/ 
 />//>//>/On Tue, Dec 26, 2023 at 3:47 AM PavelTurk  
>> wrote: />//>/Hi all, />//>/We have a Java project that must work on linux, windows, mac. To make project cross-platform 
/>/we provide jars with shared libraries - so, dll. These libraries are dowloaded with .sh script while 
/>/jar is built. We have libraries for linux and windows, but mac library is on macports. 
/>//>/Could anyone say how to donwload build/package, for example, for project `ffmpeg` using curl or wget? 
/>/Or what is the link to to it - http/https?/

MacPorts 2.9.0-beta1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.9.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of the major ones. You may like to focus your
testing on the new features in that list, as well as your normal usage.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

Re: Borg backup is complaining about msgpack python package version

[Joshua Root]

On 5/1/2024 23:45, Clemens Lang wrote:

For reasons I don't understand, borgbackup wants to allow-list every new
version of the msgpack library manually, so every update of the msgpack
library breaks borgbackup.


It's likely because many python module projects have a culture of very 
poor backward compatibility practices. Interfaces change in incompatible 
ways all the time, often without the compatibility break being 
documented. I would assume a past minor version increase of msgpack 
broke borgbackup, which created a support burden for them, so now they 
pin the version.


This is bad for basically everyone, because client projects stick with 
old versions with old bugs out of caution even when newer ones would 
work fine (as in this case), it creates extra work when they do update, 
and it's really easy to get into situations with diamond dependencies 
where conflicting versions of the same module are required. This one 
issue is largely responsible for the need to have a separate venv for 
every project, each with identical or only slightly different copies of 
many of the dependencies.


And unfortunately, this is a social issue with no easy fix. :(

- Josh

Re: Borg backup is complaining about msgpack python package version

[Joshua Root]

On 6/1/2024 00:07, Clemens Lang wrote:

Actually, the relevant commit is
https://github.com/borgbackup/borg/commit/39761ebadc9325a7cc7e931144e2709effe8f0f0,
and that has been backported to the 1.2 branch of borgbackup and is in
1.2.7, so just make sure you have the latest borgbackup installed and it
should start working again.


Yes, updating to 1.2.7 was the resolution to the ticket that was opened 
about this. 


- Josh

MacPorts 2.9.0-rc1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.9.0-rc1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no show-stopping bugs are found in the next few days, this will
become the 2.9.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since beta1 are:
* Version number only.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

MacPorts 2.9.0-rc2 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.9.0-rc2 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no showstopping bugs are found in the next few days, this will become
the 2.9.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since rc1 are:
 * Fixed error when running 'port diagnose'.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

Re: /opt/local/var/macports

[Joshua Root]

Are there negative side-effects to moving this largish subdirectory to an 
external drive and connecting via soft link?


I haven't tried it myself in a while, but as far as I know having it on 
another volume should work fine. You don't need the link, since this 
location is configurable as 'portdbpath' in macports.conf. The negative 
effects are really just the usual effects of using an external drive. 
Builds and registry operations will be limited by the drive's speed, and 
there will be an additional performance penalty when activating ports 
because the files are extracted in the software directory and then moved 
into place, and that move will be across volumes with this configuration.


- Josh

MacPorts 2.9.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.9.0 version has now
been released. It is available via the usual methods:

   - selfupdate if you already have MacPorts installed
   - package installers [1] for macOS 14 Sonoma and all older releases
 back to Mac OS X 10.4 Tiger  (universal arm64/x86_64 for macOS 11+,
 i386/x86_64 for 10.6, i386/ppc for 10.4 and 10.5, and the rest
 x86_64)
   - source tarballs, both .tar.bz2 [2] and .tar.gz [3]
   - git tag [4]

The list of what's new in 2.9.0 can be found in the ChangeLog [5].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.9.0, and to all those who helped out
by reporting bugs or testing.

Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [6].

- Josh

[1] 
[2] 

[3] 


[4] 
[5] 
[6] 

PS, my PGP key ID is 0x01FF673FB4AAE6CD,
fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD



OpenPGP_signature.asc
Description: OpenPGP digital signature

MacPorts 2.9.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.9.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 14 Sonoma all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1] 
[2] 
[3] 
[4] 



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Port reclaim unexpectedly wants to uninstall a subport, when the top level port is installed

[Joshua Root]

I'm puzzling over some weird "port reclaim" behaviour on one machine.  On the problematic machine, 
I installed py-matplotlib, which correctly installed py312-matplotlib.  But, if I run "port 
reclaim", it wants to uninstall py312-matplotlib as a "Unrequested ports without requested 
dependents found".

Then the script that I have that needs py-matplotlib fails.  I know I could 
request py312-matplotlib, but that then leads to a bit more work cleaning 
things up when I move to python313.

On the second machine, everthing works as expected.

Is there something I can do to rebuild the registry, assuming this is the 
problem?


Possibly you had previously installed py-matplotlib when an older python 
version was the default? In any case, running 'sudo port upgrade 
py-matplotlib' will refresh its registry data.


- Josh

Re: is there a Fortran-90 compiler port? Where to get a FOSS Fortran-90 compiler?

[Joshua Root]

Are you sure of that? Check e.g. 'port contents gcc13 | grep gfortran'.

- Josh

Kenneth Wolcott wrote:


Hi Noam;

   I do not have gfortran, therefore I must not have gcc?

Here is a filtered list of the ports that I have installed that pertain to gcc:
   gcc12 @12.3.0_4+stdlib_flag (active)
   gcc12-libcxx @12.3.0_4+clang14 (active)
   gcc13 @13.2.0_4+stdlib_flag (active)
   gcc13-libcxx @13.2.0_4+clang16 (active)
   gcc_select @0.1_10 (active)
   libgcc @7.0_0 (active)
   libgcc12 @12.3.0_4+stdlib_flag (active)
   libgcc13 @13.2.0_4+stdlib_flag (active)
   mpich-default @4.1.2_2+gcc13 (active)

Still confused...

Thanks,
Ken W.

On Fri, Mar 1, 2024 at 6:03 PM Bernstein, Noam CIV USN NRL WASHINGTON
DC (USA) https://lists.macports.org/mailman/listinfo/macports-users>> wrote:
>//>/Pretty sure that macports gcc installs gfortran by default, which is 
a f90 (and 95, and maybe f2003) compiler./

Re: is there a Fortran-90 compiler port? Where to get a FOSS Fortran-90 compiler?

[Joshua Root]

Yes. Or as Eric suggested, you can use 'port select' to create a 
'gfortran' link.


- Josh

On 2/3/2024 15:35, Kenneth Wolcott wrote:

Should I be using gfortran-mp-13?

ls /opt/local/bin | grep fortran
arm64-apple-darwin23-gfortran-mp-12
arm64-apple-darwin23-gfortran-mp-13
gfortran-mp-12
gfortran-mp-13
lfortran

Re: MacPorts vs. Apple compiler issues, Handle

[Joshua Root]

MacPort installs:
$ clang-mp-9.0 --version
clang version 9.0.1

Apple:
$ clang --version
Apple LLVM version 9.1.0 (clang-902.0.39.1)

Is there some Apple "trick" or is it the slight compiler difference in
version?


The version difference is less slight than you might think. Apple clang 
version numbers are unrelated to the version number of the llvm.org 
release they are based on. Apple clang 9.1.0 is closest to the clang-5.0 
port.


The name collision looks genuine however. I can only assume that 
MacTypes.h is not included or is preprocessed differently based on 
different defines in the other compiler.


- Josh

Re: MacPorts vs. Apple compiler issues, Handle

[Joshua Root]

On 13/3/2024 20:52, Riccardo Mottola wrote:
I found a minor patch by Firefox to solve this namespace collision. So 
for whatever reason Apple's did differently, it now compiles on all 
compilers.


However clang9 generates a crashing executable. I tried on both 10.11 
and 10.13.


- Apple clang: works fine
- MacPorts clang 7: compiles & works
- MacPorts clang 9 : compiles but fails

anybody has seen this behaviour in other software, perhaps smaller and 
easier to test than ArcticFox?


Yes, any number of programs have had bugs that only became apparent when 
building with a newer compiler. But that's a very broad category, so 
without knowing the nature of the crash you're seeing, it's impossible 
to say what else might have had a similar problem.


Bugs in clang are not unknown, but far more common is programs relying 
on certain behaviour for operations that have undefined behaviour 
according to the language standard. Or sometimes the layout of memory 
just shifts slightly, causing a previously benign buffer overflow to do 
damage. Sometimes a newer compiler will also default to a newer version 
of the language, so if that's the cause of the differing behaviour, you 
can use -std to change it back.


Otherwise, you have to do the hard work of debugging: Look at the crash 
report to see where and how the code is crashing, pay attention to 
compiler warnings, and systematically eliminate possibilities of what 
could be going wrong. Building with clang's sanitizers may be helpful, 
particularly -fsanitize=address and -fsanitize=undefined, though in a 
code base this size I wouldn't be surprised if they also detected 
hundreds of other potential issues.


- Josh

Re: ld: can't write output file for architecture ppc

[Joshua Root]

raf wrote:


I've been told that macports needs to be selfupdated at least annually.
If it's been too long between selfupdates, it can fail (It did for me once
on 10.6.8). You might need to reinstall macports instead of selfupdate.

To any expoerts out there, does that sound helpful?


I wouldn't uninstall just yet, and definitely not without making a 
backup first, as it will remove the possibility of easily restoring the 
old versions.


When you upgrade, MacPorts will only deactivate the old versions of 
ports (unless specifically told to immediately uninstall them). So you 
should be able to activate the older versions to get back to the state 
you were in previously. It should be pretty obvious which is which based 
on the timestamps in 'port -v installed'.


If you want to try to go ahead with upgrading, I would first 'port 
deactivate active' and then 'port install' (not upgrade) the ports you 
want to use. That will still use anything you already have installed if 
possible, saving some build time, and will avoid any issues with ancient 
variants, replaced ports and such.


If that still fails, you still have the option of reactivating the old 
versions.


- Josh

Re: MacPorts vs. Apple compiler issues, Handle

[Joshua Root]

(Moving to macports-dev as it is a better fit for this topic.)

On 18/3/2024 22:50, Riccardo Mottola wrote:
I will do another compilation reducing the optimization level. GCC has 
an issue where beyond gcc6 certain optimizations need to be disabled, or 
AF crashes.


Issues that only appear at higher optimisation levels also often involve 
undefined behaviour.



Exception Type:    EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   KERN_INVALID_ADDRESS at 0x7ffe2007


So here is what happened: SIGSEGV means the program tried to access 
memory that it should not have. The page was not mapped or had the wrong 
permissions for what it was trying to do. The memory address that it 
attempted to access is also shown.



Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   XUL       0x00010f5468e1 
nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, 
char const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, 
nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273


And this is where it happened. Since this is not a full debug build, 
there is no line number information, but you at least know which method 
is doing the bad memory access.


- Josh

Re: Library libtdbc used in restore_ports script is unsigned

[Joshua Root]

I recently upgraded from macOS 13.x to macOS 14.3.1 Sonoma and started running 
the MacPorts Migration process. I got interrupted and did the minor macOS 
update to macOS 14.4 and tried to run the “restore_ports.tcl” script, which 
worked for a while but then threw an error about the libtdbc library being 
unsigned. I don’t know if this is something that changed recently. What is the 
recommended procedure for fixing this? Uninstall all the ports and reinstall 
them?

This is the full error:
dlopen(/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib, 0x0006): tried: 
'/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' (code signature in 
<3CE89C0F-A387-3934-8B3D-5834290B7BD3> '/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' 
not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to 
be at least ad-hoc signed.), 
'/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' (no such 
file), '/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' (code signature in 
<3CE89C0F-A387-3934-8B3D-5834290B7BD3> '/opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib' 
not valid for use in process: mapped file has no cdhash, completely unsigned? Code has to 
be at least ad-hoc signed.)
 while executing
"load /opt/local/lib/tdbc1.1.7/libtdbc1.1.7.dylib Tdbc"
 ("package ifneeded tdbc 1.1.7" script)
 invoked from within
"package require tdbc"
 (file "/opt/local/lib/tcl8/8.6/tdbc/sqlite3-1.1.7.tm" line 13)
 invoked from within


This is likely an unfortunate interaction with a feature of tclsh and a 
feature of macOS. Tcl will look for packages in the same prefix as the 
interpreter that is running the script, and in this case, the tclsh 
shipped with MacPorts base finds a tdbc library installed by a port. The 
former is signed and the latter is not, and macOS doesn't allow signed 
executables to load unsigned libraries.


The most straightforward workaround is to use a different path for the 
interpreter. /opt/local/bin/port-tclsh is a symlink to the actual 
tclsh8.6 in a subdirectory, so running the script like this should work:


sudo `readlink /opt/local/bin/port-tclsh` ./restore_ports.tcl

Hopefully we can ship automatic migration in MacPorts base soon and 
retire restore_ports.tcl.


- Josh

Re: Library libtdbc used in restore_ports script is unsigned

[Joshua Root]

On 21/3/2024 23:33, Eric Gallager wrote:

On Thu, Mar 21, 2024 at 12:53 AM Joshua Root  wrote:

Hopefully we can ship automatic migration in MacPorts base soon and
retire restore_ports.tcl.



Yeah, please notify me once this happens; I've been reluctant to
update from Big Sur just due to how much of a pain the
restore_ports.tcl process can be...


If you want to help this happen faster, please feel free to test the 
migration branch of base: 
<https://github.com/neverpanic/macports-base/tree/migration>


or this prototype I recently made of a slightly different method, which 
among other things will not reinstall ports that have 'platforms any' or 
'platforms {darwin any}': 
<https://github.com/jmroot/macports-contrib/tree/migrate/migrate>


Bear in mind this is bleeding edge stuff; there are almost certainly 
still bugs, so we'd love to know about them so we can fix them.


- Josh

MacPorts 2.9.2 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.9.2. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

 sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 14 Sonoma all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1] 
[2] 
[3] 
[4] 


OpenPGP_signature.asc
Description: OpenPGP digital signature

MacPorts 2.9.3 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.9.3. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 14 Sonoma all the way back to 10.4 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1] 
[2] 
[3] 
[4] 


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: MacPorts 2.9.3 has been released

[Joshua Root]

On 4/4/2024 15:29, Peter West wrote:
I’ve installed 2.9.3. As with 2.9.2, port selfupdate did not update the 
port install. Is this something you’re aware of?


It always takes a little time for releases to propagate to the rsync 
mirrors. 2.9.2 took longer than usual because of some downtime for the 
master server. 2.9.3 is on the mirrors now.


I’ve been installing these to try to fix the “missing m4” problem, but 
neither seemed to fix it. Should I add a comment to one of the number of 
issues in trac concerning this?


In any case, I’m downgrading to Xcode 15.1.


We don't ship m4 with MacPorts base, so a new base release won't do 
anything for missing m4 issues. Ultimately Apple needs to release a new 
command line tools version that includes m4 again, and in the meantime 
each port that uses m4 needs to either run it by the name 'gm4' instead 
(since Apple still included that), or declare a dependency on the m4 
port. If you notice a port is affected and there is no ticket open for 
it, please open one.


- Josh

Re: MacPorts 2.9.3 has been released

[Joshua Root]

Dave Horsfall wrote:


I hadn't got around to installing 2.9.2 yet (I do those admin tasks on
Mondays); will 2.9.3 drop cleanly onto 2.9.1?

I ask because I got bitten by a Linux upgrade; apparently Debian (if not
all of them) requires all intermediate upgrades be performed...


We aim for direct upgrades to work across gaps of up to one year. In 
practice, base upgrades often work with much longer gaps. Port upgrades 
often don't if there is any renaming or replacing involved.


- Josh

Re: force rebuild a port

[Joshua Root]

Richard L. Hamilton wrote:


A URL likehttps://ports.macports.org/port/harfbuzz/builds/  


in your browser (but put in the port name you want in place of harfbuzz) will 
show what if anything is pre-built for that port. Other views are available, 
but don't ask me if there's one that shows everything pre-built for a specific 
macOS version; if there is one, I haven't found it. I'm just another user, not 
a maintainer, and not familiar with everything; I knew some of these things 
were possible, but had to dig a bit to be able to describe them.


You can show only the builds from a certain OS version using the "Select 
builder(s):" popup menu. However, builds are attempted for all ports, 
not just the ones for which the archives can be made publicly available. 
To see if there is an archive available for a port, you would have to 
check the appropriate subdirectory on packages.macports.org, e.g. 
.


See the thread starting here for a previous discussion of some of the 
complexities around whether binary archives are available: 



- Josh

Re: what MacPorts port would create a TAGS file (looks like a history helper, rlwrap?)

[Joshua Root]

what MacPorts port would create a TAGS file (looks like a history
helper, rlwrap?)


https://www.gnu.org/software/emacs/manual/html_node/emacs/Tags-Tables.html

Re: Macports, pip, and vent

[Joshua Root]

I’m setting up to use a collection of python codes developed by someone else, 
and to run them I’ll need to use some python modules/packages that aren’t 
available via MacPorts (nvector, pykml, and stripy).  From looking over old 
posts it appears that the best way to do this is to install all of the packages 
available from MacPorts either in my main environment or in the virtual 
environment and the PyPI-available packages only in the virtual environment.  
I’ve not fiddled with venv stuff before - I assume that everything available in 
my main environment will also be available in the virtual environment unless it 
is “hidden” behind something installed in the virtual environment.  Is this 
correct?


This is the case only if you use the --system-site-packages option. 



If that option is used, I would guess that pip will consider 
requirements to be satisfied by MacPorts-installed modules as long as 
the version is acceptable, and install a different version in the venv 
if not. But I haven't tested that theory. Generally 
--system-site-packages is avoided in order to prevent unexpected 
behaviour changes due to the presence of random other modules. (Simple 
severe failure case: an installed module is buggy and crashes on import. 
Anything that inspects all installed modules by importing them will then 
hit that crash.)


- Josh

Re: xcode not found while building

[Joshua Root]

Ryan Schmidt wrote:


On May 26, 2024, at 14:33, Riccardo Mottola wrote:
> 
> Hi,
> 
> MacVim is difficult to build, I want to get a version build on older versions of MacOS.

> I am trying to get a version building on 10.11. The current versions and most 
previous versions don't build, because XCode 8 is expected. I have XCode 7.3.1
> 
> Going back in history I got to 8.1 155
> 
> this has build failing.
> 
> Hunk #1 succeeded at 796 (offset 27 lines).

> --->  Running ibtool for Preferences.nib
> xcode-select: error: tool 'ibtool' requires Xcode, but active developer 
directory '/Library/Developer/CommandLineTools' is a command line tools instance
> Command failed: ibtool --compile 
src/MacVim/English.lproj/Preferences.nib/keyedobjects.nib 
src/MacVim/English.lproj/Preferences.nib
> Exit code: 1
> Error: Failed to patch MacVim: command execution failed
> 
> 
> But, as said, I have XCode installed! what cold be wrong?


If you have the command line tools installed, then MacPorts uses them unless the portfile 
says "use_xcode yes".


So make sure you checked oute4b3d80 and not an earlier commit where the version 
was 8.1 155. If use_xcode is already in the Portfile you're using, you probably 
need to run xcode-select.

- Josh

Call for testing: port migrate

[Joshua Root]

A 'migrate' action has been added to MacPorts base in git on the master 
branch. If you are comfortable with checking out the git repo, 
installing MacPorts from source, running potentially buggy pre-release 
code, and reporting any issues, we would greatly appreciate you giving 
it a try.


The new action automates all parts of the existing Migration procedure 
apart from updating Xcode and the CLTs. After updating your OS to a new 
major version or transferring to a new machine with a different CPU 
architecture, you should be able to simply run:


sudo port migrate

and MacPorts base will first be rebuilt, and then all ports that need to 
be reinstalled to be compatible with your current system will be. Build 
failures should be handled as gracefully as possible and reported at the 
end.


Thanks to Umesh Singla for doing the initial work on this feature, and 
to Clemens Lang for doing much of the work of completing and updating 
the code.


- Josh

Re: Call for testing: port migrate

[Joshua Root]

Hi Franco,

Thanks for testing, and good to hear it went well.

- Josh

On 12/6/2024 19:41, Franco Vaccari wrote:

Happy to report that the migration went smoothly. Just one port installation 
finished in error (grass, and looking at the port health that was expected, so 
also qgis3 +grass wasn’t migrated) but that didn’t prevent the migration to 
complete for all other ports (944 of them).

All this on a MacBook Pro with M1 processor, macOS Sonoma 14.5, Xcode 15.4 and 
its CLT’s.

So, all in all, a very positive experience.

Thanks to the MacPorts team!

Ciao

Franco


On 12 Jun 2024, at 09:46, Franco Vaccari via macports-users 
 wrote:

Dear Josh,

since your mail caught me a few minutes after updating from Ventura to Sonoma, 
and a few seconds before I started to play with MacPorts migration, I felt 
obliged to give the migrate command a shot…

Currently computing dependency order. Will let you know the outcome…

Ciao

Franco


On 12 Jun 2024, at 09:00, Joshua Root  wrote:

A 'migrate' action has been added to MacPorts base in git on the master branch. 
If you are comfortable with checking out the git repo, installing MacPorts from 
source, running potentially buggy pre-release code, and reporting any issues, 
we would greatly appreciate you giving it a try.

The new action automates all parts of the existing Migration procedure apart 
from updating Xcode and the CLTs. After updating your OS to a new major version 
or transferring to a new machine with a different CPU architecture, you should 
be able to simply run:

sudo port migrate

and MacPorts base will first be rebuilt, and then all ports that need to be 
reinstalled to be compatible with your current system will be. Build failures 
should be handled as gracefully as possible and reported at the end.

Thanks to Umesh Singla for doing the initial work on this feature, and to 
Clemens Lang for doing much of the work of completing and updating the code.

- Josh

Re: py-numpy 2.0.0

[Joshua Root]

>/Would introducing a py-numpy2 port be a possible solution? />//>/Nils. /

Unfortunately, that’s not how python packages work.

They need to install into the same directory spaces as to be available for 
other packages, e.g.

/opt/local/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/numpy

Marius


I really don't understand why python projects don't change the module 
name when there's a major API break, given that there's no way to have 
multiple versions of a module installed and pick which one to import (at 
least not without custom code messing with importlib). Even if you 
install all your deps in a venv, you have to somehow make sure nothing 
wants numpy 1 if anything wants numpy 2.


Even installing one of the versions somewhere else and adding that 
location to sys.path isn't a good solution. If it's always there then 
dependents will still get whichever version is found first in sys.path, 
so all dependents that need it would have to be patched to add the 
sys.path entry. And even then, it would be a constant struggle to ensure 
that nothing those modules import needs the other numpy version.


- Josh

MacPorts 2.10.0-beta1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.10.0-beta1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of the major ones. You may like to focus your
testing on the new features in that list, as well as your normal usage.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: MacPorts 2.10.0-beta1 now available for testing

[Joshua Root]

Bill Cole wrote:


Surprisingly few issues, and I like the way this spat out at the end so
I didn't need to read the whole scrollback:

--->  Note:
  Migration finished with errors.
  The following ports could not be restored:
   - clang-12
 Skipped becuase its dependency llvm-12 failed
   - colima
 Skipped becuase its dependency colima failed
   - llvm-13
 Skipped becuase its dependency llvm-13 failed
   - lynx
 Skipped becuase its dependency lynx failed
   - macports-libcxx
 Skipped becuase its dependency llvm-11 failed
   - openssh
 Skipped becuase its dependency openssh failed
   - podofo
 Skipped becuase its dependency podofo failed
  The following ports were restored with changes:
   - openjdk17-zulu
 state changed from 'installed' to 'inactive'
   - openjdk21-temurin
 state changed from 'installed' to 'inactive'

(I'm surprised the misspelling made it to a beta...)


I admit I had to look twice to spot it. :)


I haven't dug into solving any of those yet, but some appear to clearly
be dependency determination problems.


I believe this was a mistake in the way the failure reason messages were 
set, and I think I've fixed it. You should find that all the ports that 
the messages say are their own dependency did actually fail to install.


- Josh

Re: MacPorts 2.10.0-beta1 now available for testing

[Joshua Root]

Nils Breunese wrote:


Bill Cole https://lists.macports.org/mailman/listinfo/macports-users>>:
> The following ports were restored with changes:
> - openjdk17-zulu
> state changed from 'installed' to 'inactive'
> - openjdk21-temurin
> state changed from 'installed' to 'inactive'
> 
In what circumstances do ‘restores’ like this happen? A change from ‘installed’ to ‘inactive’ doesn’t sound like a ‘restore’ to me, but maybe this problem is correcting a previously incorrect state? Or is this really just some form of a failure to install these ports for a newer OS? I’m asking because I maintain these two ports and I wonder if something is wrong with them.


This behaviour is consistent with these ports having been active but not 
marked as requested. By default, only requested ports and their 
dependencies are migrated. (If interactive questions are on, you get an 
"are you sure?" at the start of the process that lists ports that won't 
be migrated. There's a --all flag to include unrequested ports.) 
Normally, ports that aren't restored would end up uninstalled, but in 
this case, they are just left inactive because they are compatible with 
the current platform since they are "darwin any".


The phrasing "restored with changes" could probably be improved to 
better describe what actually happened, which is that they were 
deactivated and then not restored at all.


- Josh

MacPorts 2.10.0-beta2 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.10.0-beta2 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of the major ones. You may like to focus your
testing on the new features in that list, as well as your normal usage.

Notable changes since beta1 are:
 * `port migrate` syncs the ports tree before reinstalling ports.
 * Various fixes and improvements to error handling and reporting in 
the snapshot and restore code.


Cheers,
Josh

[1] 
[2] 
[3] 
[4] 

MacPorts 2.10.0-rc1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.10.0-rc1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no show-stopping bugs are found in the next few days, this will
become the 2.10.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since beta2 are:
* Version number only.

Cheers,
Josh

[1] 
[2] 
[3] 
[4] 



OpenPGP_signature.asc
Description: OpenPGP digital signature

MacPorts 2.10.0 has been released

[Joshua Root]

The MacPorts Project is happy to announce that the 2.10.0 version has 
now been released. It is available via the usual methods:


- selfupdate if you already have MacPorts installed
- package installers [1] for macOS 14 Sonoma and all older releases
  back to Mac OS X 10.5 Leopard  (universal arm64/x86_64 for
  macOS 11+, i386/x86_64 for 10.6, i386/ppc for 10.5, and the rest
  x86_64)
- source tarballs, both .tar.bz2 [2] and .tar.gz [3]
- git tag [4]

The list of what's new in 2.10.0 can be found in the ChangeLog [5].

A big thanks to the developers for their hard work with all of the
various features and bug fixes in 2.10.0, and to all those who helped 
out by reporting bugs or testing.


Detached PGP signatures for the pkg/dmgs and source tarballs have been
made with my key, which is available on the keyservers and my MacPorts
wiki page [6].

- Josh

[1] 
[2] 

[3] 


[4] 
[5] 
[6] 

PS, my PGP key ID is 0x01FF673FB4AAE6CD,
fingerprint C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: port outdated complains after self-update to version 2.10 of MacPorts

[Joshua Root]

port outdated
sqlite error: attempt to write a readonly database (8) while executing
query: CREATE INDEX registry.snapshot_file_id ON snapshot_files(id)
 while executing
"registry::open $db_path"
 (procedure "mportinit" line 832)
 invoked from within
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, sqlite
error: attempt to write a readonly database (8) while executing query:
CREATE INDEX registry.snapshot_file_id ON snapshot_files(id)


I'm not sure why that registry update didn't happen during installation, 
but it just needs write access to the database to succeed now, so 
running any port command with sudo should fix it.


- Josh

Re: Error upgrading to macport 10.0

[Joshua Root]

hello,

It is bizarre!
Here is what I get:
Error: Current platform "darwin 23" does not match expected platform "darwin 23"
Error: Please run 'sudo port migrate' or follow the migration 
instructions:https://trac.macports.org/wiki/Migration
OS platform mismatch
 while executing
"mportinit ui_options global_options global_variations"
Error: /opt/local/bin/port: Failed to initialize MacPorts, OS platform mismatch

What to do now?
Thanks and bests.
Raoul MEGELAS


My guess would be that you are running MacPorts through Rosetta. The new 
version detects this situation and prompts to migrate, which is what you 
want if you moved your installation from an x86_64 Mac to an arm64 one.


Unfortunately it looks like the code that prints the message wasn't 
updated to explain the reason correctly.


In any case, running `sudo port migrate` as it suggests should get you 
past this, or if you're sure that none of your ports need to be 
migrated, `sudo port selfupdate --migrate`.


- Josh

Re: Platform mismatch error

[Joshua Root]

Hello macports,

Still the same error:
As the subject says,
Platform mismatch error.
Some details:
Sonoma 14.6.1 on M1 Max 64Gb.
I reinstalled completely  macports after removing all.
And I get the same error.
What to do in this case?


I suspect you are running your terminal or shell through Rosetta as in 
this ticket: 


A fresh installation from the .pkg should work OK as long as you use a 
native terminal and shell. If you'd like to test a hopefully better fix, 
you could apply these four changes to your local files:










- Josh

Re: Platform mismatch error

[Joshua Root]

On 15/8/2024 02:35, Raoul MEGELAS wrote:

Hello Joshua

Please see the  screenshot of info:
It seems to me than open rosetta is unchecked.
Another point:
The shell is zsh (native on install).
I will try your suggestions and report.
Bests
Raoul


Could you please show the output of the following commands in the shell 
you use to run the port command?


sysctl sysctl.proc_translated
echo $SHELL
lipo -info $SHELL
lipo -info /opt/local/libexec/macports/bin/tclsh8.6

This should definitively tell us what, if anything, is running through 
Rosetta.


- Josh

Re: Platform mismatch error

[Joshua Root]

On 15/8/2024 17:04, Raoul MEGELAS wrote:

On 15 Aug 2024, at 00:48, Joshua Root  wrote:

Could you please show the output of the following commands in the shell you use 
to run the port command?

sysctl sysctl.proc_translated => 1
echo $SHELL => /bin/zsh
lipo -info $SHELL => Architectures in the fat file are: /bin/zsh
lipo -info /opt/local/libexec/macports/bin/tclsh8.6

=> x86_64 arm64


OK, so the sysctl result tells us that your shell is running through 
Rosetta. The most common reason for that is using an x86_64-only 
terminal emulator, though there are other possibilities.


Your MacPorts installation is universal, but because the shell is 
running under Rosetta, it runs MacPorts under Rosetta too. There are 
some problems with running it that way that should be fixed in the next 
release.


In the meantime, to avoid problems, you'll need to run MacPorts 
natively. If your terminal emulator is not native, switching to a native 
one will help. If all else fails, you can force commands to run natively 
by prefixing them with 'arch -arm64', for example:


arch -arm64 sudo port migrate

or start a native shell with:

arch -arm64 /bin/zsh

Hope this helps.
- Josh

MacPorts 2.10.1 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.10.1. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

 sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from macOS 14 Sonoma all the way back to 10.5 at [2]. 
The source is also available as tarballs compressed with gzip or bzip2, 
or from the git tag [3].


Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1] 
[2] 
[3] 
[4] 



OpenPGP_signature.asc
Description: OpenPGP digital signature

file conflict between qemu and dtc

[Joshua Root]

Kenneth Wolcott wrote:


circular dependency between qemu and dtc


This is not a circular dependency. Qemu (now) depends on dtc, dtc does 
not depend on qemu.



self-update

qemu fails due to conflict with dtc

deactivating dtc then trying to update qemu fails because it activates dtc


The previous version of qemu, 9.0.2_0, did not declare a dependency on 
the dtc port and installed its own copy of dtc. The current version of 
qemu, 9.0.2_1, declares a dependency on the dtc port and uses it instead 
of installing its own copy. See 
.


That unfortunately means that there is a conflict that you will see when 
upgrading qemu, because its new dependency dtc is installed before qemu 
itself is upgraded. Some code to deactivate qemu in this case needs to 
be added to the dtc port. A workaround is to deactivate the old qemu 
version, activate dtc, and then activate the new qemu version.


- Josh

Re: 2.10.1 macports SQL error on 10.6

[Joshua Root]

on my MacBook (64bit) after upgrading to macports 2.10.1, "port
selfupdate" yields:


--->  Checking for newer releases of MacPorts
MacPorts base version 2.10.1 installed,
MacPorts base version 2.10.1 available.
--->  MacPorts base is already the latest version
--->  Updating the ports tree

The ports tree has been updated.
Error: process_cmd failed: sqlite error: another row available (100)
while executing query: SELECT cxx_stdlib FROM registry.ports WHERE id=726


This looks like database inconsistency. The id column is a primary key 
and so should always be unique, meaning there shouldn't be more than one 
row that has a given id.


Hard to say how it happened. The problem could potentially have been 
there for some time, only now being detected by the additional 
constraint checking that was enabled in 2.10. Memory or disk corruption 
are possibilities.


The first step toward fixing it is to find out which ports' db rows are 
affected. Try running this: sqlite3 
/opt/local/var/macports/registry/registry.db "select * from ports where 
id=726"


If that succeeds, you should get 2 or more rows of port information. The 
port name will be in the second column. If it doesn't work, you may need 
to resort to a full database dump: sqlite3 
/opt/local/var/macports/registry/registry.db ".dump" > registry_dump.txt


Before trying anything to fix it, make a backup of your registry.db. 
It's possible that simply uninstalling the two (or more) ports that 
share the same id will fix everything. If not, more manual database 
surgery may be required. I don't know how much work it's worthwhile for 
you to put into this before deleting everything and starting again is 
the better option.


Good luck,

- Josh

Re: 2.10.1 macports SQL error on 10.6

[Joshua Root]

On 7/9/2024 02:14, Riccardo Mottola wrote:


The first step toward fixing it is to find out which ports' db rows 
are affected. Try running this: sqlite3 
/opt/local/var/macports/registry/registry.db "select * from ports 
where id=726"


sqlite3 /opt/local/var/macports/registry/registry.db "select * from 
ports where id=726"

726|xmlcatmgr|435d94eb7431bfb474662c034bffac8cbde64759424e188613ed8a7f8287ba96-1298|/opt/local/var/macports/software/xmlcatmgr/xmlcatmgr-2.2_1.darwin_10.x86_64.tbz2|0|2.2|1|||installed|1724755415|image|x86_64|0|darwin|10|none|0

apparently, there is only one line.

An miracle, if I run now "port upgrade outdated" I get no errors, fixed 
itself! but reboot or some operation was needed.


Interesting. Maybe the issue was at the filesystem level and rebooting 
triggered a fsck that repaired it, or maybe sqlite was able to 
self-repair somehow when given write access.


Is there anything else I can run to see if there is no other 
inconsistency? Or maybe it's OK?


First install the macports.sqlext port. Then run this command (all one 
line):


sqlite3 /opt/local/var/macports/registry/registry.db ".load 
/opt/local/lib/sqlite3/macports.sqlext" "PRAGMA integrity_check"


That will check that the database is internally consistent. It does not 
however check that the data is correct with respect to external factors, 
e.g. whether the files that each port is recorded as installing actually 
exist in the filesystem.



Deleting everything takes some time, so before doing it...


If you're no longer seeing errors, no need to delete anything I guess. 
It's probably worth running a test with smartctl (from the smartmontools 
port), just in case.


- Josh

Re: 2.10.1 macports SQL error on 10.6

[Joshua Root]

Bill Cole wrote:


On 2024-09-06 at 22:25:07 UTC-0400 (Sat, 7 Sep 2024 12:25:07 +1000)
Joshua Root https://lists.macports.org/mailman/listinfo/macports-users>>
is rumored to have said:

[...]
> First install the macports.sqlext port. Then run this command (all one 
> line):

>
> sqlite3 /opt/local/var/macports/registry/registry.db ".load
> /opt/local/lib/sqlite3/macports.sqlext" "PRAGMA integrity_check"


On Sonoma 14.6.1:

skinnyclam:~ root# sqlite3 /opt/local/var/macports/registry/registry.db
".load /opt/local/lib/sqlite3/macports.sqlext" "PRAGMA integrity_check"
Error: unknown command or invalid arguments:  "load". Enter ".help" for
help


This can be fixed by installing the sqlite3 port. The version of sqlite3
in the base OS is 3.43, that in the port is 3.46


Yeah, Apple started disabling loadable extensions in the system sqlite3 
a few years ago, so the macports.sqlext port depends on the sqlite3 
port. But of course you still have to make sure you're running the right 
sqlite3, so specifying the full path in the command would have been more 
reliable.


- Josh

Re: Doubly Active PHP

[Joshua Root]

When I type ‘port installed’, I notice I have 2 php8* ports (php82 @8.2.23_0 
and php83 @8.3.11_0) and both are active.
Here is the list of php ports I have:
   php82 @8.2.23_0+libedit (active)
   php82-gd @8.2.23_0 (active)
   php82-mbstring @8.2.23_0 (active)
   php82-mcrypt @1.0.7_0 (active)
   php82-mysql @8.2.23_0+mysqlnd (active)
   php82-openssl @8.2.23_0 (active)
   php82-zip @1.22.3_0 (active)

   php83 @8.3.11_0+libedit (active)
   php83-apache2handler @8.3.11_0 (active)
   php83-curl @8.3.11_0 (active)
   php83-exif @8.3.11_0 (active)
   php83-iconv @8.3.11_0 (active)
   php83-imagick @3.7.0_1 (active)
   php83-mbstring @8.3.11_0 (active)
   php83-mysql @8.3.11_0+mysqlnd (active)
   php83-pspell @8.3.11_0 (active)

   php_select @1.0_1 (active)
   phpmyadmin @5.2.1_0+php82 (active)

Some of the ports are duplicated e.g. php8*-mysql, others are not.

Is the above list to be expected?
Why do I have 2 php8* ports?
Should I do anything at all?


There are really only two reasons a port is installed:

1. Someone ran 'port install' to install that specific port, or

2. Some other port depends on it.

You can check whether any other installed port needs a given port with 
'port dependents', e.g. 'port dependents php82-gd'. If a port has no 
dependents and you don't need it for any other reason, it's fine to 
uninstall it. See 
 for more 
info.


- Josh

Re: Dependencies/Dependents

[Joshua Root]

bernard.remacle wrote:


What is the meaning of ‘rdepends’? (The manual page on port(1) is a little 
difficult to understand): I understand ‘r’ is the prefix for recursive.
What is the difference between ‘rdepends’ and ‘rdependentof’?


The rdepends: selector is the recursive version of depends:, which is a 
generalisation that matches the union of what all the depends_* 
selectors (depends_build:, depends_lib: and so on) would match. Each of 
the latter matches against the corresponding field in the PortIndex. So 
rdepends: gives you all available ports that have the specified port 
anywhere in their recursive dependencies.


On the other hand, rdependentof: is the recursive version of 
dependentof:, which evaluates to the same thing that 'port dependents' 
would print. That only considers the dependencies recorded in the 
registry, which means it only tells you about ports that are installed, 
and only about their runtime dependencies. Basically it answers the 
question, "What other installed ports would break if I uninstalled this 
port?"


Originally there were only selectors that directly matched PortIndex 
fields. Recursive and inverted ones for dependencies seemed like an 
obvious improvement, and ones that matched registry information instead 
seemed like a good idea at the time ("Hey, what if I want to use the 
result of 'port dependents foo' in an expression?"), though perhaps not 
enough thought was put into how to convey the subtle semantic difference 
to users not familiar with the internals. If there isn't good 
documentation that explains it already, that would be a great addition.


- Josh

Re: Pseudo-Portname Selectors

[Joshua Root]

When I run

port echo depends:vim

neovim-qt
p5-text-vimcolor
py-neovim
rails.vim
libvmaf
gutils-suite-core
mpvim
neovim-remote
nvimpager
vim2html
vimpager
dosfstools

(12 ports are listed)

But when I run

port echo rdepends:vim

dosfstools
gutils-suite
gutils-suite-core
gutils-suite-extra
libvmaf
mpvim
rails.vim
vim2html
vimpager

(9 ports are listed)


Another subtle semantic difference. The selectors that match against the 
PortIndex do so as a regex. But for rdepends:, there isn't really any 
sensible way to apply the same regex recursively, since the string you 
want to match changes with each level of recursion. So it just does 
exact string matching on the portname component of each depspec.


Due to depends: taking a regex that is matched on the raw PortIndex 
fields, the way to get all ports that directly depend on vim is actually:


port echo 'depends::vim(\s|$)'

because the regex "vim" will match other ports like neovim and vimpager.

- Josh

Caution: CLTs appear to be broken on Sequoia

[Joshua Root]

See  for the details.

It may be a good idea to wait a while to upgrade. If you have to use 
MacPorts on Sequoia right now, it may work best to install only Xcode 16 
without the Command Line Tools.


- Josh

MacPorts 2.5.4 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.5.4. This is a bugfix release with small changes only. See the
ChangeLog [1] for the list of changes.

If you already have MacPorts installed, the preferred method for
updating is to run:

  sudo port selfupdate

For new installs, there are also package installers available for macOS
versions ranging from 10.14 all the way back to 10.4 (10.6 is universal
i386/x86_64; 10.5 and 10.4 are i386/ppc, the rest are x86_64) at [2].
The source is also available as tarballs compressed with gzip or bzip2,
or from the git tag [3].

Detached PGP signatures for the disk images, packages and source
tarballs have been made with my key, which is available on the
keyservers and my MacPorts wiki page [4], the fingerprint being:

0x01FF673FB4AAE6CD: C403 7936 5723 6DCF 2E58  0C02 01FF 673F B4AA E6CD

Josh
(on behalf of the MacPorts Port Managers)

[1] 
[2] 
[3] 
[4] 

Re: port not installing

[Joshua Root]

Ryan Schmidt wrote:
> Your output still does not show the portindex being fetched or generated, and 
> I don't know why that would happen. In fact selfupdate appears to be exiting 
> entirely, before printing the output that should always be printed at the 
> end, as I showed before:

That may be . If so, doing sync
rather than selfupdate should show the error that is occurring.

- Josh

Re: Mojave and Migration

[Joshua Root]

Michael Newman wrote:
> I followed the migration instructions which are found here: 
> https://trac.macports.org/wiki/Migration 
> 
> 
> That sort of worked, except that some ports didn’t get reinstalled. For 
> example, neither ImageMagick nor MPlayer were reinstalled. It was easy to 
> manually install them, but now I’m wondering what else didn’t get reinstalled.
> 
> (I found out that ImageMagick didn’t get reinstalled because a script I wrote 
> which uses convert failed. MPlayer was just a random check.)
> 
> Is there any way to find our without manually checking each and every port in 
> myports.txt?
> 
> TIA

Were there any failures shown in the output of restore_ports.tcl? Were
the missing ports mentioned at all? Running it again will not do any
harm since it will simply skip any ports in myports.txt that are already
active; what happens if you do so?

- Josh