MacPorts 2.10.2 Sonoma installer updated

[Joshua Root]

Unfortunately, the MacPorts 2.10.2 installer for macOS 14 Sonoma 
contained a misconfiguration that can cause port builds to fail. Other 
macOS versions are not affected.


A new build of the installer has been uploaded. The version number is 
unchanged because it is built from exactly the same source code. The 
updated file has the following SHA256 hash:


SHA2-256(MacPorts-2.10.2-14-Sonoma.pkg)= 
128c1d50fd0a71430364c16a5bb2f0e92406c866452f323487276a8ac40ccd3c


If you installed MacPorts on Sonoma using the 2.10.2 .pkg installer 
before this message was sent, please either run:


sudo port -f selfupdate

or download and install the updated .pkg.

We apologise for the inconvenience.

Josh
(on behalf of the MacPorts Port Managers)


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Foiled Again

[Joshua Root]

On 2/10/2024 15:06, Michael Newman wrote:
I did my best with the bug report. I had no idea what to put in the 
comments section.


The Description field is for any additional information or analysis that 
is not present in the log and too long to put in the Summary. If you 
don't have anything to add, it's fine to leave it blank.



I attached what I hope is a gzip version of the main.log.

I’m a bit gun shy about creating a ticket. Last time it turned out not 
to be a port problem, but something to do with the command line tools; a 
something that I really didn’t understand.


Somehow it seems that tickets should generally be filed by people who 
actually know what they’re doing.


You accurately stated which port was failing to build and attached a 
complete log, which is already doing better than quite a few of the 
reports we get. :)


Of course we'd prefer if people didn't file duplicate tickets or file 
lots of tickets that turn out to be a general problem like the recent 
CLTs bug, but genuine bugs going unreported would be a worse outcome.


- Josh

Re: Foiled Again

[Joshua Root]

Michael Newman wrote:


This morning I upgraded my 2019 iMac to Sequoia and then did a port migrate.

I think everything went OK, except for the following:

 The following ports could not be restored:
  - nbsmtp
Failed: Unable to execute target 'activate' for port nbsmtp - see its 
log
 for details

When I look at what I think is the log, I see this at the end, which means 
nothing to me:

:error:build Failed to build nbsmtp: command execution failed
:debug:build Error code: CHILDSTATUS 70925 2
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:build invoked from within
:debug:build "command_exec -callback portprogress::target_progress_callback 
build"
:debug:build (procedure "portbuild::build_main" line 10)
:debug:build invoked from within
:debug:build "$procedure $targetname"
:error:build See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_mail_nbsmtp/nbsmtp/main.log
 for details.


About all that particular part of the log means is "running some shell 
command failed during the build phase". The relevant error will be 
earlier. This is part of why we always ask for full logs; end users 
can't be expected to know which parts of the log are relevant.



When I search for a ticket for nbsmtp I find nothing. (But I’m not very good at 
searching.)


The easiest way to check if there are any tickets open against a port is 
probably to go to its page on ports.macports.org, click "Details", and 
check the "Trac Tickets" tab. It looks like there are not any open 
tickets in this case. There's a handy "Report an Issue with this port" 
link on the same page.



What next?


Open a ticket and add the complete main.log as an attachment.

- Josh

MacPorts 2.10.2 has been released

[Joshua Root]

The MacPorts Project is pleased to announce the release of version
2.10.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 15 Sequoia 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

Re: segmentation fault during an install

[Joshua Root]

Just trying again seems to have eliminated the curl issue (after cleaning 
libmagic and first installing some other ports that were missed on the migrate 
sweep).


Typically the crash only happens when connecting to an FTP site after 
having connected to a HTTP/2 site. So availability of binaries, 
availability of mirrored distfiles, variations in ping times, and which 
other ports are fetched by the same command will all make a difference.


>/I'm in process of migrating from Sonoma to Sequoia and manually 
installing prots that were missed originally by "sudo port migrate" 
due to the CLT issue, after I removed the offending directory from the 
old CLT./


BTW, you don't have to do this manually, 'port restore' can run the 
reinstalling ports part of migration again for you. See 
.


- Josh

Re: segmentation fault when fetching from ftp

[Joshua Root]

Ryan Carsten Schmidt wrote:


On Sep 27, 2024, at 16:51, Murray Eisenberg wrote:
>//>/Does installing the MacPorts version of curl accomplish anything in 
this regard? /

Not unless you build MacPorts from source and configure it to use MacPorts curl 
but that's not recommended because your MacPorts will become nonfunctional if 
you ever deactivate MacPorts curl because it will say it cannot find the 
libcurl library.

The bug is already fixed in MacPorts base master so you could build MacPorts 
base master from source and it will work with macOS curl.


If you're going to install from git, using the release-2.10 branch is a 
bit safer.


I mentioned some other possible workarounds in the ticket: 



- Josh

Re: Requested Ports

[Joshua Root]

Michael Newman wrote:


I did what Arno suggested (thank you) and I now have a requested.txt file that, 
as far as I can tell, is a good representation of both:

• The ports I migrated to this machine when I first set it up last October.
• The ports that I later installed.

What I still don’t understand is what happened to the ports that I either 
migrated or installed?

Many of them simply disappeared after I upgraded to Sequoia and used the new 
MacPorts migration procedure.

Fifteen:desktop mnewman$ xargs -n1 sudo port setrequested < old_requested.txt
Password:
Error: exiftool is not installed
Error: jshon is not installed
Error: lynx is not installed
Error: mailutils is not installed
Error: msmtp is not installed
Error: nano is not installed
Error: nbsmtp is not installed
Error: tree is not installed

(old_requested.txt is the file I used to migrate to the new machine and which I 
recovered from TimeMachine.)

Where did they all go?


I don't know exactly what you did, but assuming you ran 'port migrate' 
at some point in the process and didn't delete the snapshot afterwards, 
you can compare the snapshot with your installation's current state by 
finding the snapshot ID with 'port snapshot --list' and then running 
'port snapshot --diff  --all' where  is the appropriate ID number.


Migration will only restore requested ports and their dependencies by 
default (and there should have been a message telling you about any 
ports that would not be restored, and a prompt asking if you want to 
continue), so it's possible you will find that some of the ports you 
want were not marked as requested when the snapshot was created. If 
that's the case, you can run 'sudo port restore --last --all' to restore 
all of the ports in the snapshot including unrequested ones.


- Josh

Re: several ports cannot be installed due to a Perl circular dependency hell...

[Joshua Root]

Error: The following dependencies were not installed because all of
them have unmet dependencies (likely due to a dependency cycle):
p5.34-authen-sasl p5.34-net-smtp-ssl p5.34-cgi
p5.34-pod-coverage-trustpod p5.34-test-simple p5.34-pod-eventual
p5.34-mixin-linewise p5.34-sub-exporter p5.34-data-optlist
p5.34-params-util p5.34-config-autoconf p5.34-file-slurper
p5.34-test-warnings p5.34-cpan-meta-check p5.34-module-pluggable
p5.34-module-runtime p5.34-module-build p5.34-software-license
p5.34-data-section p5.34-text-template p5.34-io-socket-ssl
p5.34-io-socket-ip p5.34-uri p5.34-html-parser p5.34-html-tagset
p5.34-http-message p5.34-clone p5.34-b-cow

Re: Tcl mess

[Joshua Root]

Ryan Carsten Schmidt wrote:


On Sep 23, 2024, at 03:29, Christoph Kukulies wrote:
> 
> How can I overcome this?


I'm not sure. I haven't seen this before. It almost sounds like the selfupdate 
didn't fully work and didn't fully update the bundled copy of Tcl. Try 
installing MacPorts using the installer from our web site.


It looks like reclaim was actually run by the old base version before 
exiting, after it had selfupdated. This isn't safe, as ably demonstrated 
by what happened next. There's no need to reinstall anything, since 
future commands will be fully running the new base version.


The good news is, this shouldn't be able to happen any more with 2.10.x.

- Josh

Re: Migration Errors after Sequoia

[Joshua Root]

I still can’t install msmtp because:

Error: Failed to build gss: command execution failed

I hesitate to file a bug report on this problem because it appears that there 
is already a bug report on gss (#70869), but I can’t tell if mine would be a 
duplicate of that.


The only way to be certain is to compare the error in your log with the 
one in the ticket. But it's very likely the same problem.



So, how should I proceed now? Just wait for the gss issue to be resolved?


Yes, once a ticket has been filed, there's not much else you can do to 
move the process along unless you have the ability to contribute a fix 
yourself. Someone just has to figure out what's causing the issue and 
how to fix it, and implement the fix.


- Josh

Re: failed migration to Sequoia

[Joshua Root]

On 21/9/2024 21:18, Artemio González López wrote:

 julia 

:info:build curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in 
connection to github.com:443
:info:build make[1]: *** [/opt/local/var/macports/build/ 
_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_julia/julia/work/julia-1.10.5/deps/srccache/LLVMLibUnwind.v12.0.1+0.aarch64-apple-darwin.tar.gz] Error 35


It looks like it's trying and failing to download files in the build 
phase (which we'd like to avoid but should normally work). You might 
need to open a ticket for this one.



 py32-scipy 

:info:build * Getting build dependencies for wheel...
:info:build ERROR Missing dependencies:
:info:build     pythran>=0.12.0
:info:build     gast~=0.5.0




P.S. I just have one more question: when 'port restore —last’ runs, it 
rebuilds everything again from scratch or just the ports that failed to 
build in the previous run?


Ports that were active when the snapshot was created and are not 
installed now will be installed, which will mean building them if a 
binary archive is not available. Ports that are already installed will 
be deactivated and then activated again, which should be very fast on APFS.


- Josh

Re: failed migration to Sequoia

[Joshua Root]

On 21/9/2024 03:36, Artemio González López wrote:


I just ran port selfupdate, but the only outdated port it found is xorg- 
libXi  (which I updated). I guess it is not worth to give port restore — 
last another try, since the problematic por was libgcc14, which hasn’t¡t 
been updated. Am I right? I would also like to know whether anybody else 
who, like me, got rid of the c++ directory one way or another (and with 
an M1 chip) is having the same problem with libgcc14. If this is the 
case perhaps something else is going on, apart from the rogue c++ 
directory problem.


A port can only be considered outdated if you have an older version 
installed, so if you have never been able to install any version, it 
will not be shown as outdated. There have definitely been updates to 
libgcc14 in the last several days, so depending on when you previously 
selfupdated, it may now work.


Yes, some users are still having problems with libgcc14 after fixing the 
SDK and the -pipe problem, see the ticket I previously referenced: 
 But it seems to be working for 
others.


- Josh

Re: failed migration to Sequoia

[Joshua Root]

On 20/9/2024 08:27, Artemio González López wrote:


Before reading your message, I deleted the directory /Library/Developer/ 
CommandLineTools and reinstalled the Command Tools for Xcode 16 (which I 
also have installed) from scratch using the dmg at the Developer 
website. This should be equivalent to what you propose, since I have 
checked that the c++ directory is absent from a fresh installation of 
the Command Line tools:


artemio@mbp-13 Downloads % l /Library/Developer/CommandLineTools/usr/ 
include/c++


ls: /Library/Developer/CommandLineTools/usr/include/c++: No such file or 
directory


Yes, that also works.

Unfortunately, after executing supo port restore —last I got exactly the 
same error as before (libgcc14 and lib sodium failed, and cause several 
ports, like emacs-app, not to compile). I do not know what else to do. 
Could executing "sudo port selfupdate” before “sudo port restore —last” 
help, or could it mess up things with the ports that have been 
deactivated by the previous restore commands? Is there anything else I 
should try? By the way, I am running things on a 2019 M1 13” MacBook Pro.


You should definitely run port selfupdate, because that is how you get 
the latest changes to the ports, which includes the fixes for many of 
the Sequoia and Xcode 16 problems.


- Josh

Re: failed migration to Sequoia

[Joshua Root]

On 19/9/2024 18:30, Artemio González López wrote:


Thanks, Josh! In fact, I renamed the /Library/Developer/CommandLineTools and 
got most of my ports to succesfully build after executing “sudo port restore 
—last”. Unfortunately, there is still a problem with libgcc14 that prevents 
emacs-app to compile:

Migration finished with errors.
 The following ports could not be restored:
  - emacs
Skipped because its dependency libgcc14 failed
  - emacs-app
Skipped because its dependency libgcc14 failed
  - gnuplot
Skipped because its dependency wxWidgets-3.0 failed
  - julia
Skipped because its dependency libgcc14 failed
  - py311-matplotlib
Skipped because its dependency libgcc14 failed
  - py311-scipy
Skipped because its dependency libgcc14 failed
  - py312-matplotlib
Skipped because its dependency libgcc14 failed
  - py312-scipy
Skipped because its dependency libgcc14 failed
 The following ports could not be fully restored:
  - py311-jupyter
Skipped because its dependency libsodium failed
state changed from 'installed' to 'inactive'
  - py312-jupyter
Skipped because its dependency libsodium failed
state changed from 'installed' to 'inactive'
  - py312-jupyterlab
Skipped because its dependency libsodium failed
state changed from 'installed' to ‘inactive'

(There is also a problem with libsodium, but that seems less important). Is 
this problem known? Does anybody suggest a fix/workaround, while things are 
ironed out?


A lot has happened since my last reply. We're no longer recommending 
uninstalling the Command Line Tools, because a more surgical fix has 
been found: 


I believe gcc14 may be one port that really wants the CLTs, so restoring 
them would be step 1. One fix for gcc14/libgc14 build failures has 
already been committed, but there seems to be another one affecting some 
users. This is the ticket tracking the issues: 



If you can't get libgcc14 working in the short term, you should be able 
to install emacs and emacs-app by turning off the default nativecomp 
variant.


As for libsodium, which version did you see the failure with? It was 
only just updated to 1.0.20.


- Josh

Re: what setting to use to force only arm64 (Apple Silicon) binaries/libraries, no universal ports?

[Joshua Root]

Clearing universal_archs in macports.conf will disable universal entirely.

Some ports that don't support arm64 may still install as x86_64 if they 
don't require any universal dependencies.


- Josh

Fix for CLTs C++ issue

[Joshua Root]

For those who haven't been following the ticket, we've determined that 
the problem is caused by the CLTs installer not deleting everything left 
over from older versions when updating, combined with some unfortunate 
logic in how clang++ constructs its include paths. Fresh CLTs 
installations are therefore not affected, but ones that have been 
updated over time can be.


The proper fix will be hopefully be in future installers, but for now 
you can do it yourself by running:


sudo rm -rf /Library/Developer/CommandLineTools/usr/include/c++

- Josh

Re: failed migration to Sequoia

[Joshua Root]

Artemio González López wrote:


Yesterday I tried to migrate my Sonoma MacPorts installation to the newly 
installed Sequoia on a 2019 M1 MacBook Pro 13”. I used the new procedure, i.e.,

sudo port migrate

The procedure produced the following errors:

<...>


It seems that there is currently a problem with cmake-bootstrap, which affects 
many ports, and to a lesser extent with db48, lzip and lz4. Does anybody know 
when these ports are expected to be fixed? Would there be a way of restoring a 
port (for example, emacs.app, which I use a lot), to its former version before 
the migration (which worked1)? The migration documentation also mentions to try

sudo port restore —last

to try to reinstall the ports that failed once they are fixed. Is there any 
downside to this if I try and some of the problematic ports have not been fixed?


The main problem would be this: 

The short version is that the Command Line Tools fail to build C++ code 
for some users. We're not yet sure what determines whether they work or 
not. If you're affected, uninstalling the CLTs and using Xcode seems to 
be an effective workaround.


The migration process uninstalls all ports built for a different OS 
version, so unfortunately you won't be able to get back the Sonoma 
version of emacs.app using port commands. You would have to restore from 
a backup.


Running 'sudo port restore --last' will deactivate all currently 
installed ports, and then attempt to activate all ports recorded in the 
snapshot that was created during migration, building and installing if 
needed. So the only downsides are that it takes some time, and if you 
have installed any new ports since the snapshot was created, they may 
end up inactive and need to be manually activated.


- 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

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

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: 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: 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: 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]

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

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

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

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

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]

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: 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: 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

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

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-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] 

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

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

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: 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

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

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: 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

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: 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: 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: 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: 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

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

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

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

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: 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: 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]

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: 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: 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: 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: 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

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

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

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-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] 

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] 

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

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

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: 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?/

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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: Issue with installing port

[Joshua Root]

I'm trying to get pandoc to install.

The ticket for this is , FWIW.

- Josh

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: 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: 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: 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]

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: 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: 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: 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: 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: 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: 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: 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