Re: Bug in curl Variant +http3?

[Ryan Schmidt]

On Jun 12, 2024, at 13:49, Eric Hoch wrote:
> 
> Shall I file a bug report for this?

Yes, you should file a bug report with the developers of curl. 

Re: How to report an error?

[Ryan Schmidt]

On May 29, 2024, at 07:38, Bill Cole wrote:
> 
> I think the solution is likely to be removing some of the 6(!) different 
> versions of the package currently in MacPorts and creation of proj_select to 
> handle the link.
> 
> All of the versioned proj* ports have the same maintainer but the unversioned 
> one (which is v5.2.0) has none. That is odd, and I don't understand how that 
> happens...

Please see https://github.com/macports/macports-ports/pull/23462 for the work 
in progress to fix this. 

Re: xcode not found while building

[Ryan Schmidt]

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". 

Re: Fix: My dovecot install fails after macOS Sonoma 14.5 update and MacPorts update

[Ryan Schmidt]

On May 22, 2024, at 16:25, Gerben Wierda wrote:
> 
> I was able to circumvent this autoconf failure by installing gettext before 
> installing dovecot, I don't know if that is the best solution, but ot works 
> (as in, it now installs).

Yes that is the solution and I committed it here:

https://github.com/macports/macports-ports/commit/8addb4df7ea4e8da28e059e28052f68b8bad02cb

Only when you use the +apns variant, dovecot regenerates the configure script 
from configure.ac (because it applies a patch to configure.ac). configure.ac 
references the AM_ICONV macro so the port that provides that macro must be 
present at build time. From its name it seems like the AM_ICONV macro should be 
provided by the libiconv port but for whatever reason it's actually provided by 
the gettext port.

Re: [OT] bad disk & MacOS reinstall

[Ryan Schmidt]

On May 18, 2024, at 01:46, Richard L. Hamilton wrote:
> 
> dyld[16578]: Symbol not found: (_gtk_plug_construct)
>   Referenced from: '/opt/local/lib/libgtkmm-3.0.1.dylib'
>   Expected in: '/opt/local/lib/libgtk-3.0.dylib'
> Abort

Are you using the quartz variant? This error was mentioned before here:

https://trac.macports.org/ticket/65743

Re: Dovecot install Error

[Ryan Schmidt]

On May 18, 2024, at 00:21, Horst Simon wrote:
> 
> Could not open /opt/local/lib/mysql8/mysql/libmysqlclient.24.dylib: Error 
> opening or reading file (referenced from 
> /opt/local/lib/dovecot/libdovecot-sql.0.dylib)

This is https://trac.macports.org/ticket/70001

Re: [OT] bad disk & MacOS reinstall

[Ryan Schmidt]

On May 17, 2024, at 17:57, Riccardo Mottola wrote:
> 
> Does Macports have a tool to get SMART details?

The one that occurs to me is:

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

Re: [unable to compile MPICH v4.2.1 with GNU toolchain v13.2.0 @ macOS Sonoma v14.4.1]

[Ryan Schmidt]

On May 13, 2024, at 21:35, Ryan Schmidt wrote:
> 
> What I found before said that the problem had been fixed in gcc 11.1. 

It was pointed out in that issue today that newer gcc will still experience the 
problem when in C99 mode. 

https://trac.macports.org/ticket/69632#comment:11

Re: Port Question and Suggestion

[Ryan Schmidt]

On May 14, 2024, at 15:19, Frederick Weinhaus wrote:
> 
> Question:  I have a question about which port to install when there are 
> several ports related to the name. What is the difference between portname, 
> py-portname, and py312-portname?  Which should be installed?
> 
> For example:  tiff, py-tiff, py-tifffile, py312-tifffile

Read the port description in e.g. "port info tiff". If that's not sufficient, 
read the web page by running e.g. "port gohome tiff". 

The tiff port installs libtiff, a library someone made for reading and writing 
tiff files from C code. It also includes a couple related command line 
programs. 

Ports whose names begin with py312- are modules for python version 3.12.x and 
similarly for the other "py" prefixes with different numbers. tiff and tifffile 
are two different python modules created by two different people. If you want 
to deal with tiff files from python you might want one of these. 

Ports whose names begin with py- are stubs that install nothing. Their only 
purpose is to declare a dependency on the version of this module for the most 
recent or recommended version of python that is available. For example if you 
install py-tifffile it will install py312-tifffile for you so that you can use 
that module from python 3.12.x, the recommended python version in MacPorts for 
2024. 

I tried "port gohome py-tiff" and was told the server does not exist. From 
"port info py-tiff" I can see that it depends on py27-tiff, meaning it is 
probably so old it is not compatible with python 3. The homepage URL contains 
"2004" making me think the software is twenty years old. So I don't recommend 
trying to use this module anymore. On the other hand, the tifffile module 
released a new version a few days ago so it appears to be current and 
supported. 

> I have installed py312-opencv already.  Which tiff port should I install?

It depends on what you want to do with it. Do you want to use tiff files with 
the python opencv module? Consult the opencv module's documentation to see how 
to do that; maybe it's built in or maybe they suggest to install tifffile or 
another module. 

> Suggestion:  It would be very helpful if the port search results in the 
> Available Ports search was sorted alphabetically when returned.

Issues related to the ports web site can be filed here:

https://github.com/macports/macports-webapp/issues

But I assume the results are intentionally sorted by relevance, not 
alphabetically. 

Re: [unable to compile MPICH v4.2.1 with GNU toolchain v13.2.0 @ macOS Sonoma v14.4.1]

[Ryan Schmidt]

On May 13, 2024, at 10:07, Maxim Abalenkov wrote:
> 
>> If you want to build anything from source on macOS, use clang unless there 
>> is an extremely good reason to use gcc.
> 
> When you say clang, do you recommend using Apple’s clang or clang from 
> MacPorts?

Whichever you like. Whichever works for you. Apple's clang is convenient 
because it is already installed. If it does not work for you, you can try a 
MacPorts clang. Take care to understand that the MacPorts clang ports are 
versions of llvm.org clang which is different from Apple clang. They have 
different version numbering schemes and sometimes different capabilities. 

> One extremely good reason to use gcc is the ability to have a Fortran 
> compiler. I need an MPICH distribution with Fortran compiler wrappers and 
> Fortran modules.

The MacPorts mpich port offers this via its several sub ports, for example the 
mpich-gcc13 sub port. Yes, this uses gcc13, but in this case it has hopefully 
already been tested and verified to be working by a MacPorts contributor. 


>> You said in the subject line that you're using gcc 13.2.0 but that's not 
>> confirmed by the log. When I researched this error recently, I found that 
>> this bug was fixed in gcc 11.1 which makes me think you are actually trying 
>> to use a gcc version older than that. See 
>> https://trac.macports.org/ticket/69632
> 
> I set gcc to point to mp-gcc13 with a MacPorts command:
> 
> sudo port select --set gcc mp-gcc13

That should work. 

> In my Perl script I ensure FC, CC and CXX environment variables point to 
> compilers in /opt/local/bin/{gcc,g++,gfortran}. Is there any other way to 
> verify that I’m using the right version of GNU compilers?

You can run "gcc --version" to verify. If it says you are indeed running gcc 13 
then I cannot explain the error. What I found before said that the problem had 
been fixed in gcc 11.1. 

Re: [unable to compile MPICH v4.2.1 with GNU toolchain v13.2.0 @ macOS Sonoma v14.4.1]

[Ryan Schmidt]

On May 13, 2024, at 05:36, Maxim Abalenkov wrote:
> 
> Dear all,
> 
> How are you? I hope all is well with you. I need help please. I’m struggling 
> to compile MPICH v4.2.1 (from source code) with the GNU toolchain v13.2.0 @ 
> macOS Sonoma v14.4.1. Please see my configuration and installation Perl 
> script attached. I also attach a full log of the compilation errors. I 
> recently installed GNU toolchain via MacPorts. When the script proceeds to 
> compilation, it crashes with the following error messages:
> 
> Compiling MPICH...
> In file included from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/_types.h:32,
>  from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/_types.h:27,
>  from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/pthread.h:55,
>  from ../../../modules/yaksa/src/util/yaksu_atomics.c:6:
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:30:
>  error: missing ')' after "__has_attribute"
>   554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)
>   |  ^
> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/sys/cdefs.h:554:31:
>  error:  ':' without preceding '?'
>   554 | #if __has_cpp_attribute(clang::unsafe_buffer_usage)
> 
> I suspect that Apple compilers’ header files are picked up erroneously. Is 
> this normal for GNU toolchain to rely on Apple SDK’s header files? I’m new to 
> Apple CPUs. Would you please educate me, what is the suggested way of 
> installing software on Apple M? processors from source? Or should I just save 
> the pain and install my code using Apple’s native toolchain? Thank you for 
> your help and have a productive week ahead!

If you want to use mpich, the easiest solution is to use MacPorts to install 
it. 

If you want to build anything from source on macOS, use clang unless there is 
an extremely good reason to use gcc. 

You said in the subject line that you're using gcc 13.2.0 but that's not 
confirmed by the log. When I researched this error recently, I found that this 
bug was fixed in gcc 11.1 which makes me think you are actually trying to use a 
gcc version older than that. See https://trac.macports.org/ticket/69632

In your script the flag -I /opt/local/include/unistring/cdefs.h will not help 
anything because /opt/local/include/unistring/cdefs.h is not a directory that 
contains headers. 

Re: Preventing other software from linking against MacPorts libraries

[Ryan Schmidt]

On May 10, 2024, at 09:57, Smith wrote:
> 
> Thanks all for the replies. The software depends on openssl, libpng and 
> libjpeg.

And the name and version of the software that depends on those?

> In the past with other projects I left MacPorts in place but used Homebrew to 
> install these dependencies, or just built those dependencies from scratch. 
> It's not a "bad" thing for them to link to MacPorts libraries per se.  

Having Homebrew and MacPorts installed at the same time is likely to cause you 
problems. If you're building software manually, you could end up linking 
against one library from MacPorts and another library from Homebrew which is 
not only messy but might actually be incompatible if the two libraries are 
related. 

It's even possible, if you install a MacPorts port that has to build from 
source, that it is hard coded to look for Homebrew first and fall back to 
MacPorts, in which case your MacPorts port is now linked with a Homebrew 
library.

For these reasons we don't support having Homebrew installed at the same time 
as MacPorts and recommend you pick one package manager and uninstall the 
other(s). 

May I ask why you do not want to link your program with MacPorts libraries if 
linking with Homebrew libraries is acceptable? Why are they ok and we aren't? 
What can we change to become ok?


> Some of this might be due to my installing binary pre-built ports, which seem 
> to not be code signed or not signed by me. I don't know if I were to install 
> all ports in source form and build them locally would resolve some of my 
> issues. I'm not sure how to cause port to reinstall everything installed from 
> source and to use source ports rather than binary ports going forward. I'm 
> sure it is documented somewhere...

On Apple Silicon, everything is at least ad-hoc signed because that's what the 
toolchain does by default. On earlier systems most things are not signed 
because that's what the toolchain does by default.

As far as I know there would be no difference if you built from source, except 
that it would take a lot longer, use a lot more energy, and you might encounter 
build failures. So I don't know why you would want to avoid the binaries we 
spend so much effort providing. But if you do:

https://trac.macports.org/wiki/BinaryArchives#disable

Re: Preventing other software from linking against MacPorts libraries

[Ryan Schmidt]

On May 9, 2024, at 01:03, Smith wrote:
> 
> I occasionally run into a problem where I'm building software from a tarball 
> or a git clone outside of MacPorts, and the build process somehow ends up 
> linking or trying to link against libraries in the MacPorts space 
> (/opt/local). How can I prevent this from happening? Sometimes I just end up 
> deleting /opt/local to get it to build and then re-install MacPorts, which 
> can be painful or at least tiresome. I have to assume there is a better way 
> or that I'm doing something wrong?

It depends on the software you're building and the libraries it's finding. 

Some software finds its dependencies using pkg-config. If that's what's 
happening here, you can prevent it by deactivating the pkgconfig port. 

Some software that builds with CMake uses its capabilities to find things. 
Sometimes it uses pkg-config for this and other times it checks a predefined 
list of paths, which includes standard system directories and MacPorts and 
Homebrew locations. (The MacPorts version of CMake is patched to remove the 
Homebrew references.) If this is what's happening, I'm not aware of a way to 
prevent CMake from finding libraries installed in those paths. For each such 
library, you may need to supply a CMake argument telling it where the library 
you want it to use is located, or to disable the use of that library. Consult 
the documentation for the program you are building to discover what options it 
has for this. 

Some software just has a hard coded list of paths where it looks for things 
(like CMake does). If this is what's happening, and the software doesn't let 
you override those choices, you can patch its build system to remove the 
references to /opt/local or to change them to something else. 

If you need help with a specific situation, let us know what software you're 
building and what library it's finding and we can try to figure out how that's 
happening. 

Re: where is the MacPorts gcc?

[Ryan Schmidt]

On May 3, 2024, at 23:12, Kenneth Wolcott wrote:
> 
> I want to compile some C code using gcc to compare against clang.
> 
> This code I want to compile needs gsl/gsl_vector.h so I used -lgsl to
> compile with clang and it complained at runtime: "dyld[16321]: missing
> symbol called".

Since using gcc on macOS is unusual and possibly fraught with its own unique 
problems, and you encounter the issue with clang as well, let's focus on clang 
first. 

Can you provide a minimal reproduction recipe? A .c file and the command you 
used to compile and link it that demonstrates the problem and that we can try 
on our systems?

Re: where is the MacPorts gcc?

[Ryan Schmidt]

On May 4, 2024, at 02:06, Eric Gallager wrote:
> 
> `ar` and `nm` are wrappers around the corresponding tools from
> binutils/cctools; 

ar manipulates archives. nm shows you what symbols are in an object file. More 
about that in their documentation:

https://sourceware.org/binutils/docs/binutils/ar.html

https://sourceware.org/binutils/docs/binutils/nm.html

Re: where is the MacPorts gcc?

[Ryan Schmidt]

On May 3, 2024, at 23:12, Kenneth Wolcott wrote:
> 
> I think "mp" means multiple precision...

The "mp" suffix in gcc file names means "MacPorts". This is anachronistic now 
but it made sense back when gcc was included in Xcode. We wanted the executable 
"gcc-4.2" to mean Apple's fork of gcc-4.2 from Xcode even if the user had 
installed the gcc42 port (since Apple's fork supported things most users 
expected, like support for -arch flags) so we added the "mp" suffix to ours to 
differentiate them. 

Re: Many "permission denied" errors.

[Ryan Schmidt]

On Apr 22, 2024, at 10:14, Carl Witthoft wrote:
> 
> sudo port -f activate xorg-xorgproto
> error message is 
> Warning: Failed to execute portfile from registry for xorg-xorgproto @2024.1_0
> --->  Activating xorg-xorgproto @2024.1_0
> Error: port activate failed: mkdtemp failed: Permission denied

You should almost never force port activation so let's drop the -f flag. 

Can you try again with debug mode -- the -d flag? Maybe that will tell us more. 

I recall two or three users reporting difficulties years ago that ended up 
being caused by incorrect permissions on /tmp or /private/tmp so you might 
check those. 

Re: Fetching port getmail fails

[Ryan Schmidt]

On Apr 19, 2024, at 18:24, Horst Simon wrote:
> 
> What I tried to explain is that the curl I used in previous installs was from 
> MacPorts, but when it failed I had only the macOS High Sierra native curl.

That's what I thought you meant, but I don't think you've achieved that.

You wrote:

> after adding changing
> the root profile using /usr/local/bin and /usr/local/sbin it worked ok

I assume you mean that you edited the shell startup file of the root user so 
that /usr/local/bin and /usr/local/sbin are included in its PATH environment 
variable.

I further assume that you either meant /opt/local instead of /usr/local or that 
you have built MacPorts from source and specified the configure arguments 
--prefix=/usr/local --with-unsupported-prefix when doing so, since using 
/usr/local as your MacPorts prefix is not recommended.

If that's what you did, then that will affect what commands are available when 
you use a root shell but it will not affect which curl MacPorts uses.

MacPorts doesn't use the curl executable. It uses the libcurl library. Which 
one it uses is determined at configure time. If you use MacPorts installed from 
our installer, it uses /usr/lib/libcurl.dylib. If you build MacPorts from 
source, you can have it use whatever curl you like by using the 
--with-curlprefix configure argument, except that using the libcurl installed 
by MacPorts is not recommended because if you ever deactivate the curl port, 
then you would not be able to run MacPorts anymore because it would not be able 
to find the libcurl library anymore.

To overcome this, some users who want to have MacPorts use a newer libcurl than 
their OS provides build curl from source in some other prefix and configure 
MacPorts to use that, or they install curl in a second copy of MacPorts that 
they build from source in some other prefix and then build their primary copy 
of MacPorts from source, using the libcurl from the second copy of MacPorts.

We try to keep things working so that this is not necessary, e.g. by having a 
network of mirror servers, making mirror servers available over http for old OS 
versions whose libcurls can't access https anymore, etc. When you find 
situations like this one with getmail where it's not working, just report it to 
us and we'll figure out what needs to be fixed.

Re: Fetching port getmail fails

[Ryan Schmidt]

On Apr 19, 2024, at 17:17, Horst Simon wrote:
> Yes, this was the problem, it used the macOS High Sierra curl, after adding 
> changing 
> the root profile using /usr/local/bin and /usr/local/sbin it worked ok.

I'm not sure what you're referring to with the root profile. But after writing 
my message to the list I manually put the missing file onto the MacPorts 
distfiles server so that you could fetch it from one of our mirrors, and I 
updated the getmail port to include a second download location. 

Re: Fetching port getmail fails

[Ryan Schmidt]

On Apr 19, 2024, at 00:15, contextnerror wrote:
> 
> The issue is that you’re getting too many redirects for the pyropus.ca url. 
> I'm not sure why this is happening to you and not me.

You probably use different versions of macOS and therefore different versions 
of curl. This is a bug in curl versions released between 2014 and 2022. 

https://trac.macports.org/ticket/67186

Re: Poppler Build Error

[Ryan Schmidt]

On Apr 17, 2024, at 06:45, Curtis Matz wrote:
> 
> I’m haven’t an issue compiling poppler.  Has anyone else seen this issue?
> 
> :info:build Traceback (most recent call last):
> :info:build   File "/opt/local/bin/g-ir-scanner", line 99, in 
> :info:build from giscanner.utils import dll_dirs
> :info:build   File "/opt/local/lib/gobject-introspection/giscanner/utils.py", 
> line 385, in 
> :info:build import distutils.cygwinccompiler
> :info:build ModuleNotFoundError: No module named 'distutils'
> :info:build make[2]: *** [glib/Poppler-0.18.gir] Error 1
> :info:build make[2]: Leaving directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_poppler/poppler/work/build'
> :info:build make[1]: *** [glib/CMakeFiles/gir-typelibs.dir/all] Error 2


Yes. It's just been fixed in combination with downgrading gobject-introspection 
again. 

https://trac.macports.org/ticket/69105

Re: build of rspamd and amavisd-new not working with High Sierra

[Ryan Schmidt]

On Apr 11, 2024, at 09:04, Bill Cole wrote:
> 
> I got to 
> https://github.com/DCIT/perl-CryptX/pull/99/commits/9568b3e7ce17d9e3ace6ddbfb7df2d2e387aa91f
>  which shows the patch graphically. If you are dedicated to actually using 
> the 'patch' utility with a patchfile, there should be a way to get GitHub to 
> provide that, but I don't see it.

Manually append .patch to the URL to get:

https://github.com/DCIT/perl-CryptX/pull/99/commits/9568b3e7ce17d9e3ace6ddbfb7df2d2e387aa91f.patch

Re: build of rspamd and amavisd-new not working with High Sierra

[Ryan Schmidt]

On Apr 10, 2024, at 22:59, Horst Simon wrote:
> 
> I tried to install amavisd-new on macOS High Sierra but fails in the install 
> of the dependency p5.34-cryptx, after this I tried to change to rspamd,
> but rspamd  too fails to build.
> 
> I already created request ticket for p5.34cryptx. My question is is it 
> possible to get at least on of these working on High Sierra and what is 
> needed from me.

The rspamd problem is 
https://trac.macports.org/ticket/63785. It currently cannot build for macOS 
10.14 or earlier because it uses features from a newer version of C++ than 
those earlier macOS versions can normally accommodate. 

The p5-cryptx problem is https://trac.macports.org/ticket/68470. I added a 
comment there about some similar upstream bug reports and a proposed upstream 
patch. You could try that patch and see if it solves the problem. If so we can 
add it to the port. If it doesn't solve the problem then report the problem to 
the developers so they can develop a fix. 

Re: macports2.93 p5.34-cryptx build failed

[Ryan Schmidt]

On Apr 8, 2024, at 19:10, Horst Simon wrote:
> 
> fails with building p5.34-cryptx.
>  
> Macports version 2.93
> OS High Sierra Version 10.13.6

Presumably this is https://trac.macports.org/ticket/68470

Re: always have broken files at the end of a self-update

[Ryan Schmidt]

On Apr 9, 2024, at 19:13, Alexander Newman wrote:
> 
> I have exactly the same problem, but with rygel as another affected build. 
> I've uninstalled rygel but left webkit2-gtk in place. I now just ignore the 
> rev-upgrade suggestion (n). It seems to be associated with gstreamer and 
> cmake (cmake recently updated on my Ventura machine). Last time I looked (two 
> days ago) the macports page was showing a healthy port (Sonoma on down).

The problems are occurring because gstreamer and related ports were recently 
updated to new major versions and not all ports are compatible with these new 
versions.

In the case of webkit2-gtk, gstreamer1-gst-plugins-base was updated in such a 
way that its optional gstreamergl function was disabled. webkit2-gtk linked 
with that component which is why rev-upgrade reports it as broken. webkit2-gtk 
relies on that component which is why rebuilding webkit2-gtk now fails.

In the case of rygel, it was a different problem related to the gstreamer 
update that I have filed as https://trac.macports.org/ticket/69707.

The fact that cmake was recently updated is unrelated.

Port health indicators on the ports web site are not authoritative. They merely 
reflect what happened the last time an attempt to build those ports on the 
build system was made—usually (sometimes build results are lost). It does not 
indicate what will happen if you try to build the port today. Its dependencies 
could for example have been updated to incompatible versions since the last 
time the port was built.

Re: always have broken files at the end of a self-update

[Ryan Schmidt]

On Apr 9, 2024, at 13:02, Kenneth Wolcott wrote:
> 
> At the end of each self-update I get the following error message, in
> spite of whether I respond with yes or no:
> 
> 
> --->  Updating database of binaries
> 
> --->  Scanning binaries for linking errors
> 
> Could not open /opt/local/lib/libgstgl-1.0.0.dylib: Error opening or
> reading file (referenced from
> /opt/local/lib/libwebkit2gtk-4.0.37.44.4.dylib)
> 
> --->  Found 6 broken files, matching files to ports
> 
> --->  Found 1 broken port, determining rebuild order
> 
> You can always run 'port rev-upgrade' again to fix errors.
> 
> The following ports will be rebuilt: webkit2-gtk @2.28.2+minibrowser+x11

This problem will continue until this ticket is resolved:

https://trac.macports.org/ticket/69640

Re: force rebuild a port

[Ryan Schmidt]

On Apr 5, 2024, at 12:35, Riccardo Mottola wrote:
> 
> If I do
> 
> port -n upgrade --force --no-rev-upgrade harfbuzz
> 
> 
> it completes in a matter of seconds... and the ol' MacBook isn't that fast :)
> 
> I see cleaning, uninstalling, cleaning, installing activating, cleaning... 
> but never configure/building!
> Why?

As others explained, because you're getting a pre-compiled binary from our 
servers. This is probably what you want if you suspect something has corrupted 
your local installation and you want to reinstall. 

On the other hand, if you believe there is a defect in our pre-compiled binary, 
add -s to the -n flag to force a build from source. If that fixes the issue 
you're seeing, file a bug so we can increase the port's revision (and possibly 
additional changes) so that a new corrected binary is produced. 

Re: xz 5.6.1 vulnerability; downgrade to 5.4.6

[Ryan Schmidt]

On Mar 29, 2024, at 20:10, Ryan Schmidt wrote:
> 
> it's not yet clear if or when or how [the developers] will respond to this.

The official response page from the original developer is now up and will be 
updated with more information soon:

https://tukaani.org/xz-backdoor/

xz 5.6.1 vulnerability; downgrade to 5.4.6

[Ryan Schmidt]

Today a security issue was disclosed [1] in the xz package, which contains the 
xz program (used for example by MacPorts to decompress xz-compressed source 
code archives) and the liblzma library (used by many other programs). Versions 
5.6.0 and 5.6.1 (to which the MacPorts port was updated a couple days ago) are 
affected. Josh downgraded the port to 5.4.6 which we believe is not affected, 
but as we learn more over the coming days we may downgrade even further. Please 
use the normal MacPorts commands to receive this update and do not be surprised 
that you are being "upgraded" to an older version of xz:

sudo port selfupdate
sudo port upgrade outdated

I've spent some time reading the various discussions about this incident and 
this was not a typical security issue caused by buggy code. Instead, malicious 
code was deliberately added to the xz project in small pieces over a period of 
months or years, culminating in the release of xz 5.6.0 containing an exploit 
targeting x86_64 Debian Linux users by injecting code into sshd processes. xz 
5.6.1 "improved" the code by making the exploit harder to detect. This 
particular exploit does not affect macOS but we don't yet know if there are 
other yet-undiscovered vulnerabilities that could affect macOS. 

What seems to have happened is: Two years ago, the developer of xz found his 
time for continuing to develop xz to be limited [2] and he was pressured on the 
xz mailing list to add a second official developer. That second developer was 
later promoted to release manager. The GitHub account of that second developer 
committed the malicious code. It is not yet clear whether the GitHub accounts 
of one or both of the developers were taken over by malicious actors, or 
whether one or both of the developers have been malicious actors all along. At 
this time, GitHub has suspended the accounts of both of xz's developers and 
disabled their GitHub organization's repositories so it's not yet clear if or 
when or how they will respond to this.

Undoubtedly security researchers will be scrutinizing every commit made to the 
xz project over the past two years and we'll take further action (further 
downgrades or patches) as needed. As always, although I'm listed as the 
maintainer of the MacPorts xz port, anybody may commit changes that resolve 
security issues without waiting for the maintainer's approval.

Thank you to Frank Dean for bring this issue to our attention on the 
macports-dev mailing list and to Josh for downgrading the port so quickly.


[1] https://www.openwall.com/lists/oss-security/2024/03/29/4
[2] https://www.mail-archive.com/xz-devel@tukaani.org/msg00563.html

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

[Ryan Schmidt]

On Mar 19, 2024, at 10:21, Andreas Falkenhahn wrote:
> 
>> 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. 
> 
> Hmm, how to do that please? As written above, /opt/local/bin is
> a complete mess as half of the components are from 2017 and the
> other half is from 2024. How should I restore the old versions
> here please?

As Josh explained, run:

  port -v installed

It may be easier to limit the output to just those ports that have multiple 
versions installed (of which one is active and one or more are inactive):

  port -v installed actinact

For each port it will show when you installed it. You may wish to direct the 
output to a text editor for easier analysis.

For example on my system I have:

  sqlite3 @3.45.1_1 requested_variants='' platform='darwin 21' archs='x86_64' 
date='2024-02-05T00:01:48-0600'
  sqlite3 @3.45.2_0 (active) requested_variants='' platform='darwin 21' 
archs='x86_64' date='2024-03-12T10:59:05-0500'

If I wanted to downgrade from sqlite3 @3.45.2_0 which I installed in March back 
to sqlite3 @3.45.1_1 which I installed in February, I would run:

  sudo port activate sqlite3 @3.45.1_1

If you reactivate all of the 2017 versions of your ports, you should be back to 
where you were before trying to upgrade.

Re: libiconv build fail w/macOS 14.4 (darwin/23.4.0) arch arm

[Ryan Schmidt]

On Mar 13, 2024, at 02:07, Paul Kippes wrote:
> 
> I'm
> seeing a build error with libiconv

Fixed; see https://trac.macports.org/ticket/69462

Re: DMD port

[Ryan Schmidt]

On Mar 11, 2024, at 14:25, Kenneth Wolcott wrote:
> 
>> On Mon, Mar 11, 2024 at 11:50 AM P Padil wrote:
>> 
>> The dmd port is still at version 2.088 while upstream is at 2.107.1.  Any 
>> reason it is still stuck at this ancient version?  Can it be updated?

There's a ticket about that:

https://trac.macports.org/ticket/64774


> Not only that, but could there be a version for Apple Silicon? I've
> been using a Docker container for DMD; not really convenient...

As you know there's a ticket about that too:

https://trac.macports.org/ticket/64623

Re: I just wanted to upgrade my older MacPorts version

[Ryan Schmidt]

On Mar 10, 2024, at 05:48, Riccardo Mottola wrote:
> 
> I suppose that since you got the repository in git, you just need to do a 
> "git pull" to upgrade it and subsequently "sudo port -v sync".

You don't need to run "git pull" manually. "sudo port sync" runs it for you. 

Re: I just wanted to upgrade my older MacPorts version

[Ryan Schmidt]

On Mar 8, 2024, at 06:58, xmartin wrote:
> 
> In fact, the the problem seems to be the restrictive corporate network. I was 
> able to run what is said in:
> https://trac.macports.org/wiki/howto/SyncingWithGit

Ok great. 


> The “sudo port upgrade outdated” is running, but the question know is, how 
> can I run in the future the equivalent to the older “sudo port selfupdate”?

Hopefully someday selfupdate can work over https:

https://github.com/macports/macports-base/pull/184

Unfortunately for now it only operates over rsync, so if you cannot use rsync 
on your network then you cannot use selfupdate. You can use "sudo port sync" to 
update the ports collection periodically and you can subscribe to the 
macports-announce mailing list to learn when new releases of MacPorts base are 
made, and then download the installer for that version from our web site. 

Re: I just wanted to upgrade my older MacPorts version

[Ryan Schmidt]

On Mar 8, 2024, at 03:18, xmartin wrote:
> 
> 1) You are right. The directory  /opt/local/var has always been part of 
> MacPorts. In fact, I had a backup of the older version and, obviously this 
> directory was still there… The only important difference is that now this 
> /var directory contains a new subdirectory (called /macports), and not 
> existing in the older MacPorts version, that contains the following 
> subdirectories:
> /build   /distfiles  /home /incoming  /logs  /registry  /sip-workaround   
> /software  /sources  
> and a file called pingtimes.  Most of those subdirectories contain a lot of 
> directories and files... 

/opt/local/var/macports has also always existed (well, at least since the 
project was renamed to MacPorts) but it is usually hidden. If you are now 
seeing it in the Finder, then I guess the hidden flag has gotten unset somehow. 
It won't affect MacPorts functionality. You can hide it again if you wish. 

> 2) After typing "sudo port version” I get the following answer:
> [iMac-de-Martin:~] xmartin% sudo port version
> Warning: port definitions are more than two weeks old, consider updating them 
> by running 'port selfupdate'.
> Version: 2.9.1

Great, so MacPorts was indeed successfully updated to 2.9.1, but the 
post-update sync failed to update your ports collection due to your rsync 
problem. 

Re: Building "poppler" failed

[Ryan Schmidt]

On Mar 10, 2024, at 23:08, Dave Horsfall wrote:
> 
> High Sierra 10.13.6 on ancient MBP.
> 
> Doing my weekly "port upgrade outdated", it went belly-up here:
> 
> -
> 
>--->  Building poppler   
>Error: Failed to build poppler: command execution failed 

This error is tracked here:

https://trac.macports.org/ticket/69200

And there is another problem that will prevent poppler from building on macOS < 
10.15:

https://trac.macports.org/ticket/69455

Re: I just wanted to upgrade my older MacPorts version

[Ryan Schmidt]

On Mar 7, 2024, at 06:30, Martin wrote:

> I was running an older MacPorts version on my High Sierra and wanted to 
> upgrade the version just installing the newest one 
> (MacPorts-2.9.1-10.13-HighSierra.pkg) existing for my iMac. I did it and and 
> it was made with getting no errors or warnings. 

That should have successfully updated MacPorts base. 

> However, after this installation I only see that there appeared a new 
> directory called /opt/local/var/, but the existing executables are still the 
> old ones (the ones existing in the old  /opt/local/bin directory. 

/opt/local/var has always been part of MacPorts.

Are you saying that "port version" shows an earlier number than 2.9.1? If so, 
install the pkg again and note any error messages. 

> And when I try to run “sudo port selfupdate”  I get the following error:
> 
> --->  Updating MacPorts base sources using rsync
> Error: Error synchronizing MacPorts sources: command execution failed
> Please run `port -v selfupdate' for details.
> Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
> MacPorts sources: command execution failed
> 

There should be more information about why rsync failed. Probably it is a 
problem specific to your computer (e.g. restrictive antivirus software) or 
network (e.g. restrictive corporate network). If you can't fix your computer so 
that it can talk to rsync servers, see the section "Alternatives for syncing 
the ports tree without rsync:" at https://trac.macports.org/wiki/howto

Re: mozjs102

[Ryan Schmidt]

On Mar 6, 2024, at 06:13, Gregory Dodwell wrote:
> 
> 
> Will there ever be a mozjs102 port for the Sonoma version of MacPorts 2.9.1?
> 
> I can't install Glade without it. On the MacPorts bugs re mozjs102 page 
> there's a big red 'X' near the Sonoma version. 
> 
> Any plans for an update?

Nobody maintains this port. Somebody has to volunteer to investigate and fix 
the problem. This is the bug report: 

https://trac.macports.org/ticket/68511

mozjs115 does build on Sonoma so perhaps a fix already exists that can be 
backported to mozjs102. 

And/or maybe the ports that depend on mozjs102 (currently only gjs and 
gjs-devel) can switch to mozjs115. 

Re: How to request new ports?

[Ryan Schmidt]

On Feb 5, 2024, at 11:00, lars.sonchocky-helldorf wrote:
> 
> How would I request a port of a software I need, e.g. what’s the right way to 
> do this?

You can file a ticket in Trac, setting the Type field to Request. To resolve 
it, someone has to do the work of creating the Portfile. It could be you! If 
you do, you can send us a pull request on GitHub.

Re: MacPorts 2.9.0 & Xcode 15 on Ventura

[Ryan Schmidt]

On Jan 26, 2024, at 23:29, Sriranga Veeraraghavan wrote:
> 
> My primary Mac is currently running Venture (13.6.3) but I have held off on 
> upgrading to Xcode 15 because I recall reading that there were some issues 
> with MacPorts and the linker on Xcode 15.  
> 
> With the release of MacPorts 2.9.0, does anyone know if these issues have 
> been fixed which would make the upgrade to Xcode 15 safe?  I didn’t see 
> anything specific in the release notes about this, which is why I’m asking.

Xcode 15 caused several problems which affect many ports. Fixes have to be made 
to individual ports; MacPorts base has nothing to do with it. It could take 
years to fix all the ports. 

Re: Can't build "mpv"

[Ryan Schmidt]

On Dec 24, 2023, at 21:30, Dave Horsfall wrote:
> 
> MacBook Pro (13-inch, Mid 2010), High Sierra 10.13.6.
> 
> Dunno what it is so it must be a dependency of something, but it fails 
> with:
> 
>:info:configure meson.build:1474:21: ERROR: Command 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_mpv/mpv/work/mpv-0.37.0/TOOLS/macos-sdk-version.py`
>  failed with status 127.
> 
> It's so verbose that I can't figure out what's wrong; the "main.log" is 
> attached.

That log doesn't seem to say much, other than that the real error may be in the 
file meson-log.txt. 

Re: Quartz no longer launching when an X application is invoked

[Ryan Schmidt]

On Dec 3, 2023, at 18:28, Kevin Horton wrote:
> 
> I find in ~/.zprofile
> 
> # MacPorts Installer addition on 2020-12-29_at_06:08:54: adding an 
> appropriate DISPLAY variable for use with MacPorts.
> export DISPLAY=:0
> # Finished adapting your DISPLAY environment variable for use with MacPorts.
> 
> My other machine also has a ~/.zprofile, but it only sets the PATH.  it does 
> not set DISPLAY.
> 
> I surmise that MacPorts stopped fiddling with DISPLAY sometime between late 
> 2020 and late 2021.  Maybe there should be some automatic check of DISPLAY in 
> .zprofile, and a it could offer to clean it up if needed.

The MacPorts 2.6.4 installer for macOS 11 inadvertently added the DISPLAY=:0 
setting to shell startup files. The bug was corrected in MacPorts 2.7.0 but no 
code was ever added to clean up the mess for users who had already used the 
2.6.4 installer. 

https://trac.macports.org/ticket/61649

Could you file a new ticket to do that cleanup? Bonus points if you want to 
submit a pull request to implement it. See:

https://github.com/macports/macports-base/pull/218#issuecomment-739666236

Re: Quartz no longer launching when an X application is invoked

[Ryan Schmidt]

On Nov 30, 2023, at 16:01, Kenneth Wolcott wrote:
> 
> 3. My DISPLAY environment variable is set to ":0";
> I do not know where this variable is not being set properly or is
> being overridden.

You need to figure out where DISPLAY=:0 is being set, and remove the code that 
does so. It's probably in your shell startup file. Depending on which shell you 
use, there are many possible names for startup files in your home directory: 
.zshrc, .zprofile, .bashrc, .bash_profile, etc.

Setting DISPLAY=:0 was correct in Mac OS X 10.4 and earlier but it has not been 
correct since Mac OS X 10.5.

Re: ruby-select problem - Sonoma

[Ryan Schmidt]

On Oct 20, 2023, at 19:44, Chris F wrote:
> 
> I have created an appropriate .bash_profile (as described in the Guide) and 
> everything appears normal now.

You are using bash on Sonoma? The default shell is zsh. The MacPorts installer 
is supposed to detect which shell you use and configure the appropriate shell 
startup file but maybe it's not identifying your shell properly. Of course, if 
you changed your shell from zsh to bash after installing MacPorts that would 
explain it. 

Re: Unistalling gmic-gimp macport

[Ryan Schmidt]

On Oct 11, 2023, at 06:23, Michal Sidorczyk wrote:
> then I followed this instruction:
> 
>  
> 
> https://guide.macports.org/chunked/installing.macports.uninstalling.html
> 
>  
> 
> to remove macports completely. However, /opt/local still contains data (I 
> assume it is all macports related) and it is 2.7GB big. Can I just remove it 
> manually safely?
> 

The uninstallation instructions fully remove MacPorts and include removing 
/opt/local. If you still have that directory you haven't followed the 
instructions. 


> Moreover, it seems the uninstall procedure is pretty far from cleaning 
> everything. As I said installation of gmic-gimp port alone took 10GB. Not 
> even mentioning the other part of macports. Now, after removal of all the 
> ports, only 3GB of disk space was released. Adding 2.7GB from /opt/local 
> makes it 5-6GB the top. Are there any other macports’ leftovers I should 
> remove manually?
> 

Uninstalling MacPorts doesn't uninstall Xcode or the command line tools. You 
can find instructions from Apple for how to remove those if you wish. Xcode 
takes an extraordinary amount of disk space these days. The command line tools 
are fairly small. 

Xcode sometimes creates CoreSimulator caches which are fairly large. MacPorts 
does not need these caches but we have not been able to suppress their 
creation. See ticket #67592. You can delete these caches. 

If your computer needed to allocate swap space for virtual memory while 
building, it's possible that some of it is still allocated. You can clear any 
allocated swap space by restarting your computer. This also deletes any 
temporary files that might not have been removed by their creators. 

Re: Unistalling gmic-gimp macport

[Ryan Schmidt]

On Oct 11, 2023, at 02:03, Henning Hraban Ramm wrote:
>  Am 11.10.23 um 07:34 schrieb Michal Sidorczyk:
>> 
>>  
>> I know there are some upgrade instructions, but I did not follow them, I 
>> admit. Having the problem with disk space I do not put even more overhead of 
>> it, without being certain that eventually I will get rid of this extra 10GB 
>> space.
>>  
>> Can you help me with my problem to remove gmic-gimp from my drive?

The error message you encountered can be overcome by installing MacPorts for 
macOS Sonoma. It should not need any more disk space than is already being used 
by MacPorts. 
> Just remove the complete MacPorts installation (/opt/local), you can’t use it 
> anyway on a different platform.
> 
Just removing /opt/local is not the correct way to uninstall MacPorts. The 
correct way is documented in the MacPorts Guide. 

Re: [unable to compile and link C++ code with g++ 12.3]

[Ryan Schmidt]

On Sep 20, 2023, at 11:57, Maxim Abalenkov wrote:
> 
> I’m unable to run the ‘xcodebuild —version’. It complains:
> 
> xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer 
> directory '/Library/Developer/CommandLineTools' is a command line tools 
> instance

Use xcode-select to select Xcode rather than the command line tools. 

Re: Timing of MacPorts Support for New macOS Versions

[Ryan Schmidt]

On Sep 21, 2023, at 00:26, Bryan Jones wrote:
> 
> Dear MacPorts:
> 
> I write to propose a policy change: a MacPorts release for a new macOS major 
> version should be publicly available by the time Apple publishes the final 
> Release Candidate version of macOS.
> 
> Rationale: MacPorts is an annual problem for me. I’m a Mac developer who 
> needs to install beta versions of macOS for testing my apps. But once I do 
> that, I can’t use MacPorts to build dependencies. Even if I install the macOS 
> betas on a clean partition, I *need* MacPorts to re-build those dependencies 
> (or I have to switch back to an older partition and copy the files manually 
> into /opt/, etc.)
> 
> The lag between the release of a new major macOS version and the release of a 
> supported MacPorts version should be eliminated. MacPorts is a key part of 
> the development environment and each year it essentially goes AWOL just when 
> developers need it most: when we’re updating apps to support the new macOS 
> release! No one expects MacPorts to be ready when the first beta comes out. 
> But there are five months between the first beta and the release of macOS, 
> which seems like enough time to at least have an “RC” version of MacPorts 
> ready for developers. 
> 
> Thank you.

Hi Brian. There are a number of pieces to supporting a new macOS version in 
MacPorts. I didn't quite follow the problem you were reporting (you said you 
"can't use MacPorts to build dependencies" but didn't say why) so I'm not 100% 
sure which of these pieces you're talking about, so let me say some things 
which may or may not already be obvious to you and you can reply to whichever 
of these you're concerned about.

You should be able to install MacPorts on macOS Sonoma right now, as you could 
at any time since the first beta was released. There is no MacPorts installer 
package for Sonoma yet so you would have to build it from source. Instructions 
are in the documentation. You can try both building the current version, 2.8.1, 
and the latest code in the git master.

You can then test whether MacPorts works on Sonoma. I don't think we've 
received any reports of it not working, but if it doesn't work, and you know 
the fix, you can submit a pull request. If you don't know the fix and want to 
report it somewhere, then the issue is that pre-release versions of macOS are 
made available to you under an NDA, so you shouldn't file a public bug report, 
but should discuss the bug privately with others who have agreed to that NDA. 
The list of those people is in the wiki. Maybe one of them can fix the problem.

Eventually, once we believe MacPorts works on Sonoma, hopefully not long after 
the public release of Sonoma, Josh will create an installer package. If 
MacPorts 2.8.1 works on Sonoma, he'll make an installer package of 2.8.1 for 
Sonoma; otherwise, fixes will have to be committed to macports-base first and 
then he'll release MacPorts 2.8.2 for all OS versions. Making the Sonoma 
installer package would require that Josh have access to a machine that can run 
Sonoma. I don't know if he has that.

There are some server-side components to new macOS version support as well. The 
master build server generates portindexes for each OS version. I already added 
macOS 14 to that list two months ago, so portindexes for Sonoma have been 
available for awhile. Had I not done that, you would still be able to use 
MacPorts on Sonoma, you would just be generating the portindex locally, which 
due to the large number of ports we now have in our collection can take several 
dozen minutes.

I need to set up build machines for Sonoma on x86_64 and arm64. Until I do 
that, installing any port will build it from source on your system. It 
typically takes several weeks to do the initial builds of all ports on a new 
macOS version. Of course, many of those builds might fail, depending on what 
Apple changed in the new OS. It will take time for any interested members of 
the community to notice, investigate, and fix such problems.

For arm64, we have only one Apple Silicon Mac mini donated to us by Mac Stadium 
that switches between macOS 11, 12, and 13, and the disk is full; there is no 
room to add macOS 14. I could eliminate the macOS 11 environment and replace it 
with macOS 14. Or I could ask Mac Stadium if there is a way to swap our machine 
for one with a bigger disk. Or I could follow up with another party who has 
offered MacPorts the use of another Apple Silicon Mac mini.

For x86_64, I don't have any hardware that can officially run Sonoma (or 
Ventura). The hardware I have that runs Ventura unofficially may run Sonoma 
unofficially as well, but it will depend on the OpenCore Legacy Patcher project 
releasing a Sonoma-compatible version which they anticipate will happen at an 
unspecified time later this year. Or I would have to get a supported Mac, like 
a 2018 Mac mini. If I did that, I would probably use it for Ventura builds as 
well. Possibly, either 

Re: checksum error on tree-sitter-go-mod

[Ryan Schmidt]

On Aug 5, 2023, at 15:17, ppadilcdx wrote:
> 
> I always do a selfupdate before doing the ports' upgrades. Did a clean and 
> tried again just to make sure it wasn't corrupted on download. Not a clue how 
> to find out if it is a stealth update.

I've filed a bug report for you in which I've analyzed the problem and 
explained what happened and what we need to do to fix it:

https://trac.macports.org/ticket/68105

Re: trufflehog checksum fail

[Ryan Schmidt]

On Aug 1, 2023, at 22:37, Frank Cusackwrote:
> 
> 1. did the failed version (3.45.3) of trufflehog actually have some error 
> with checksum? or is this a macports anomaly.

A mistake was made when upgrading trufflehog to 3.45.3 on July 28: the 
maintainer forgot to update the checksums:

https://github.com/macports/macports-ports/commit/f18fffa5a99710f3699513f71acb92fe8bdca77d

Therefore, nobody could install this version; everybody received a checksum 
mismatch.

The problem was resolved when the maintainer updated the port to 3.46.2 on 
August 1:

https://github.com/macports/macports-ports/commit/91151652aa71bf6bb55efe75129e3b9b508530f6

> 2. do you agree macports has a bug re: forced, non-prompted, build deps 
> upgrades?

If you ask MacPorts to install or upgrade a port, it must upgrade your 
dependencies first, so this is intentional.

You can run into problems if you upgrade some but not all ports. Therefore we 
recommend users always use "sudo port upgrade outdated" and not try to upgrade 
ports individually (unless that is then followed up quite quickly with 
upgrading any remaining outdated ports).

Re: Problem with binutils

[Ryan Schmidt]

On Aug 7, 2023, at 07:57, Maxim Abalenkov wrote:
> 
> Hello Christoph,
> 
> How are you? Have you tried to deactivate the ‘gdb’ first as the message 
> suggests?
> 
>   port deactivate gdb
> 
> Then you may be able to install ‘binutils’ and activate the ‘gdb’ again.

This is the bug report tracking this problem:

https://trac.macports.org/ticket/43591

Help resolving it is of course welcome.

Re: How to target older macOS version

[Ryan Schmidt]

On Aug 19, 2023, at 09:12, Andreas Falkenhahn wrote:

> I've installed MacPorts on a macOS 13 system but I'd like to build programs
> that run on all systems that have at least macOS 11. That's why I run gcc
> with the -mmacosx-version-min=11.0 argument. This, however, leads to warnings
> of the following kind during linking:
> 
>ld: warning: dylib (/opt/local/lib/libfreetype.dylib) was built for newer 
> macOS version (13.0) than being linked (11.0)
>...more similar warnings for other dylibs installed by MacPorts...

This is happening because /opt/local/lib/libfreetype.dylib was not built with 
the deployment target you wanted, either because you built it from source 
without having specified that you wanted the macOS 11.0 deployment target or 
because you received our Ventura binaries which were built for the macOS 13.0 
deployment target.


> Is there any way to install the dylibs for macOS 11.0 on a macOS 13 system

Within MacPorts, there is not.

> or how am I supposed to build MacPorts programs on macOS 13 that run on older
> macOS versions as well?

If this is your goal, then you would edit macports.conf and set 
"macosx_deployment_target 11.0". If you also want to use the macOS 11 SDK as 
someone suggested, you would additionally set "macosx_sdk_version 11". There is 
no macOS 11 SDK on Ventura so you would also have to acquire that SDK (either 
manually from an earlier version of Xcode or the command line tools, or by 
installing the MacOSX11.sdk port) and put it in the right place.

These macports.conf options are undocumented and while they are supposed to 
work, not many people use them, so you may run into a fair number of ports that 
don't support them properly. If you find such ports, those would be bugs that 
ideally should be fixed, but it usually stems from build systems that are going 
out of their way to force their own deployment target or SDK selections so it 
can take a bit of work to convince those build systems not to do that.

You would also have to set "buildfromsource always" to prevent getting our 
binaries. If you already installed any ports, you should probably uninstall 
them and then reinstall them so they get built for your desired deployment 
target.

You may want to use a MacPorts prefix other than /opt/local for these 
activities. By doing that, you'll automatically build from source since our 
binaries are only used when the prefix is /opt/local. You'll also want to 
change the applications dir (for example to an Applications directory inside 
your prefix) and disable startup items. These settings leave open the option of 
having a normal MacPorts prefix at /opt/local for when you just want to install 
something quickly (using our binaries) for the current macOS.


I agree with the other responders who said it is easier to build on the OS 
version you're targeting. That's what we do for our buildbot workers (one 
worker per OS version). If your machine supports booting to macOS 11, you can 
install it on a separate volume and boot to it when needed. If it doesn't, or 
if rebooting is inconvenient, you could set up a virtual machine (with VMware 
Fusion, VirtualBox, Parallels Desktop, etc.) to run a macOS 11 environment 
within your current macOS version.

Re: DDD 3.3.12 (arm-apple-darwin22.4.0) gets Xt error (installed from source via MacPorts)

[Ryan Schmidt]

On Apr 16, 2023, at 13:35, Kenneth Wolcott wrote:

>  Here's an email that I sent to the GNU ddd mailing list.  I'll
> forward the reply I received shortly.  Looks like ddd and xQuartz are
> not compatible?
> 
> Thanks,
> Ken Wolcott
> 
> -- Forwarded message -
> From: Kenneth Wolcott
> Date: Sat, Apr 8, 2023 at 1:49 PM
> Subject: DDD 3.3.12 (arm-apple-darwin22.4.0) gets Xt error (installed
> from source via MacPorts)
> To: ddd
> 
> 
> Hi;
> 
>  I installed (from source) the ddd port from MacPorts.
> 
>  I'm on a Mac Mini running Ventura 13.3.1 (M1 chip).
> 
>  I'm using Xquartz (from MacPorts).
> 
>  All I did was "ddd return".
> 
>  Here's the contents of the ~/.ddd/log file:
> 
> GNU DDD 3.3.12 (arm-apple-darwin22.4.0)
> Copyright (C) 1995-1999 Technische Universitt Braunschweig, Germany.
> Copyright (C) 1999-2001 Universitt Passau, Germany.
> Copyright (C) 2001 Universitt des Saarlandes, Germany.
> Copyright (C) 2001-2009 Free Software Foundation, Inc.
> 
> Compiled with GCC Apple LLVM 14.0.3 (clang-1403.0.22.14.1)
> Requires X11R6, Xt11R7, Motif 2.3.8 (Motif Version 2.3.8)
> Includes XPM 3.4.11, Athena Panner (702L), Manual, App defaults, DDD core
> Built 2023-04-02 by (unknown).
> $  ddd
> !  Xt error: Unresolved inheritance operation
> !  Xt error
> !  Cannot save options

Here is the many-year-old MacPorts ticket about that:

https://trac.macports.org/ticket/50463

There is a comment that was added to it a few months ago with an alleged 
solution though it looks unusual to me.


On Apr 16, 2023, at 13:36, Kenneth Wolcott wrote:

> -- Forwarded message -
> From: Eickeler, Stefan
> Date: Sun, Apr 16, 2023 at 5:39 AM
> Subject: DDD 3.3.12 (arm-apple-darwin22.4.0) gets Xt error (installed
> from source via MacPorts)
> To: Kenneth Wolcott
> Cc: Michael Eager
> 
> 
> Hi Ken,
> 
> 
> the error message is generated by XQuarz. It seems to be an
> incompatibility of DDD and XQuarz during the initialization phase of
> the GUI.
> 
> 
> You can try the new release 3.4 of DDD. We did a complete cleanup of
> the build process. Perhaps it works better with XQuarz, but we did
> only minor changes to the initialization phase.
> 
> 
> http://alpha.gnu.org/gnu/ddd/ddd-3.4.0-rc2.tar.gz

I'll try updating the port to 3.4.0.

Re: port install hyper as a binary fails due to lack of arm64 variant (M1 chip)

[Ryan Schmidt]

On Apr 14, 2023, at 23:01, Kenneth Wolcott wrote:

> port install hyper (build from source) fails (see bug #67241)

I see the maintainer has not responded to the ticket. If you like, you could 
file a bug report with the developers and see if they have any suggestions for 
how to resolve this problem.


> port install hyper as a binary fails due to lack of arm64 variant (M1 chip)

Naturally; we can't provide a binary if we cannot build that binary.

Re: ports.tar owner/group

[Ryan Schmidt]

On May 7, 2023, at 19:42, Kastus Shchuka wrote:

> After running port sync I see files extracted from ports.tar owned by a 
> non-existent group with numerical id 505:
> 
> $ ls -l 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/
> total 474776
> -rw-r--r--   1 root  admin   20472245 Apr 30 17:46 PortIndex
> -rw-r--r--   1 root  admin512 Apr 30 18:29 PortIndex.rmd160
> drwxr-xr-x  30 root  505  960 Jan 30 18:30 base
> -rw-r--r--   1 root  admin  114272256 Jan 30 18:51 base.tar
> -rw-r--r--   1 root  admin512 Jan 30 18:51 base.tar.rmd160
> drwxr-xr-x  65 root  505 2080 Apr 30 19:21 ports
> -rw-r--r--   1 root  admin  108322816 Apr 30 18:29 ports.tar
> -rw-r--r--   1 root  admin512 Apr 30 18:29 ports.tar.rmd160
> 
> All files in ports.tar are owned by buildbot:buildbot or numerically 500/505.
> 
> drwxr-xr-x  0 buildbot buildbot0 Mar 29 17:36 ports/
> -rw-r--r--  0 buildbot buildbot  234 Nov 16  2020 ports/.gitattributes
> drwxr-xr-x  0 buildbot buildbot0 Nov 26 10:09 ports/.github/
> -rw-r--r--  0 buildbot buildbot   84 Nov 16  2020 ports/.gitignore
> -rw-r--r--  0 buildbot buildbot 1476 Mar 29 17:36 ports/.mailmap
> -rw-r--r--  0 buildbot buildbot 1996 Feb  8 23:57 ports/LICENSE
> 
> drwxr-xr-x  0 500505 0 Mar 29 17:36 ports/
> -rw-r--r--  0 500505   234 Nov 16  2020 ports/.gitattributes
> drwxr-xr-x  0 500505 0 Nov 26 10:09 ports/.github/
> -rw-r--r--  0 50050584 Nov 16  2020 ports/.gitignore
> -rw-r--r--  0 500505  1476 Mar 29 17:36 ports/.mailmap
> -rw-r--r--  0 500505  1996 Feb  8 23:57 ports/LICENSE
> 
> 
> As I don't have local user with id 500 and neither I have group with id 505,
> I end up with files owned by unknown group.
> 
> I think it is a side effect of extracting ports.tar by user root which can 
> preserve original numeric ids.
> 
> I wonder if extracted tarball should be forced to root:admin ownership after 
> extraction.
> 
> Or do I need to create local user buildbot:buildbot (500:505) to continue 
> using binary packages?

You should not need to do anything. I agree that the use of the 500 uid and 505 
gid is untidy when those users don't exist on your system (or may exist but be 
some random user or group not related to this tarball), but as far as I know it 
should not cause any problems. These just happen to be the uid and gid of the 
buildbot user and group on the server that creates the tarball.

Ideally I should fix the problem on the server by having it use fakeroot to 
change all the user and group names to macports when creating the tarball, but 
I haven't done that yet.

Re: how to prepare an existing Macports instance for an xCode update or fix Macports after xCode update?

[Ryan Schmidt]

On Jun 2, 2023, at 13:53, Kenneth Wolcott wrote:

> how to prepare an existing Macports instance for an xCode update or
> fix Macports after xCode update?

No preparation is needed.

> I have an xCode update notification.
> 
> I have an existing MacPorts installation.
> 
> Do I need to do anything to the MacPorts installation prior to the xCode 
> update?

No.

> Do I need to do anything to the MacPorts installation after the cxCode update?

No.


After upgrading Xcode, make sure you open it once and complete any prompts, 
including installing "additional components" and possibly agreeing to a 
license. You can quit Xcode after completing these steps.

If you have the command line tools installed, it's probably best to install the 
CLT version that matches the Xcode version you have. You can download Xcode and 
the CLT from the Apple developer download page.

Re: Portfile question for 10.6.8

[Ryan Schmidt]

On Jun 6, 2023, at 20:16, raf wrote:

> That still leaves the question of how 10.6.8 hosts can download distfiles
> from a non-https site (when https sites won't support TLS 1.0). Do distfiles
> magically end up on http://distfiles.macports.org?

Yes. Well, it's not magical, but it is automatic. When commits are made to the 
master branch of macports-ports, a notification is sent by GitHub to our 
buildbot system. It evaluates each commit and determines which of the ports 
that were modified need to be built. For each one, it downloads its distfiles 
(if they haven't already been downloaded) to the distfiles area of a private 
fileserver, and then it builds it for each compatible macOS version. After a 
successful build, binary archives are uploaded to the packages area of the 
private fileserver. On an hourly basis, the contents of the private fileserver 
are mirrored to the public master fileserver, and within hours after that, the 
other MacPorts mirror servers synchronize their contents with the master.

If you like to watch what the buildbot is doing you can visit 
https://build.macports.org/waterfall

Each of our mirror servers have different capabilities and requirements when it 
comes to https. MacPorts is configured to know which mirror server is able to 
be reached via https on each version of macOS. The code that does that is here 
for distfiles:

https://github.com/macports/macports-ports/blob/dbf0d04659eb119cdec6a4c3fef6247345c6/_resources/port1.0/fetch/mirror_sites.tcl#L410-L464

and here for archives:

https://github.com/macports/macports-ports/blob/dbf0d04659eb119cdec6a4c3fef6247345c6/_resources/port1.0/fetch/archive_sites.tcl#L3-L55

Re: mongodb 6.0 - No mongo or mongosh binaries

[Ryan Schmidt]

On Apr 7, 2023, at 07:02, Steven Green wrote:

> After updating mongodb to version 6.0, there is no longer a mongo executable, 
> which is how you normally connect to it from a command line.
> 
> The mongo web site says "The legacy mongo shell was deprecated in MongoDB 5.0 
> and removed in MongoDB 6.0. The new MongoDB Shell, mongosh, offers numerous 
> advantages over the legacy shell.".
> 
> However, I can not find mongosh in any ports either. Am I overlooking a port?

Looks like this is a separate software package now for which someone will need 
to make a new port. I filed a ticket to track that:

https://trac.macports.org/ticket/67210

I don't plan to work on creating the port myself because mongosh uses nodejs 
and npm and I don't recall how we deal with that kind of software in MacPorts.

Re: argp.h

[Ryan Schmidt]

On Apr 7, 2023, at 04:23, Christoph Kukulies wrote:

> Am 07.04.2023 um 11:02 schrieb Christoph Kukulies:
> 
>> Anyone having an idea where the  is buried?
> 
> OK, I found in the macOS prerequisite list for macOS that the brew package 
> „argp_standalone“ is required.
> I hate mixing brew and macports.

Right, please don't; it will cause problems.

You can use the search function on the ports web site to discover if we have a 
port that provides a particular file, for example:

https://ports.macports.org/search/?installed_file=/argp.h

This shows that we do have such a port and it is called argp-standalone.

Re: sudo port -v -s install solfege fails due to qtplay

[Ryan Schmidt]

On Mar 27, 2023, at 23:20, Kenneth Wolcott wrote:
> 
> sudo port -v -s install solfege fails
> 
> sudo port -v -s install solfege
> Password:
> --->  Computing dependencies for solfege..qtplay is known to fail. Try
> to install anyway? [y/N]: n
> Error: qtplay is known to fail
> Error: Follow https://guide.macports.org/#project.tickets if you
> believe there is a bug.
> Error: Processing of port solfege failed
> 
> Is there a way to have some other app other than qtplay provide what
> solfege needs?

I filed a bug report for this:

https://trac.macports.org/ticket/67181

Re: gv: dyld[77356]: symbol not found in flat namespace '_yylex'

[Ryan Schmidt]

On Mar 26, 2023, at 21:48, Kenneth Wolcott wrote:
> 
> Running gv fails with dyld[77356]: symbol not found in flat namespace 
> '_yylex'.

https://trac.macports.org/ticket/66211

Re: Nethack fails during patching on Ventura 13.2

[Ryan Schmidt]

On Feb 6, 2023, at 14:11, Jon Lasser wrote:
> :info:patch File to patch: No file found--skip this patch? [y] 3 out of 3 
> hunks ignored--saving rejects to Oops.rej

This should have been fixed by:

https://github.com/macports/macports-ports/commit/72e4024c311b6849e0bf3f2be320b8f9aa7a266a

Run "sudo port selfupdate" and then try again.

Re: dia port (from source) fails to install on Ventura 13.1 (with M1 chip)

[Ryan Schmidt]

On Feb 5, 2023, at 13:46, Kenneth Wolcott wrote:
> 
>  The dia port (from source) fails to install on Ventura 13.1 (with M1 chip).
> 
>  The compressed install log file is attached.

Thanks for adding your log to this ticket...

https://trac.macports.org/ticket/66013

...which is hopefully now fixed. Wait an hour, selfupdate, and try again.

Re: poly2tri-c fails to install on Ventura 13.2 (with M1 chip)

[Ryan Schmidt]

On Feb 5, 2023, at 20:40, Alan Needleman wrote:
> On Feb 5, 2023, at 8:30 PM, Ryan Schmidt wrote:
>> Please run:
>> 
>> sudo port clean poly2tri-c
>> sudo port selfupdate
>> 
>> Then try again. If it fails again, please attach the new main.log file to 
>> the ticket.
> 
> That did it! Works now. Many thanks. Much appreciated!

Great! Yes, remember to run "sudo port selfupdate" or "sudo port sync" anytime 
you want to receive any changes that we've committed. It takes a little while 
after we commit a change before it is published to the rsync server, but 
typically if you wait at least an hour after we commit something that should be 
enough time.

Re: poly2tri-c fails to install on Ventura 13.2 (with M1 chip)

[Ryan Schmidt]

On Feb 5, 2023, at 20:27, Alan Needleman wrote:
> 
> On Feb 5, 2023, at 6:32 PM, Ryan Schmidt wrote:
> 
>> On Feb 5, 2023, at 16:01, Alan Needleman wrote:
>>> 
>>> I updated to Ventura 13.2 from Monterey 12..6.3 and migrated my Macports 
>>> installation. All ports installed and seem to be working fine except for 
>>> poly2tri-c-0.1.0_0.darwin_22.arm64. It downloads and then gets to 
>>> “installing patches”  and hangs so I kill the process (I haven’t seen any 
>>> error message in the log file).
>> 
>> This was filed here:
>> 
>> https://trac.macports.org/ticket/66851
>> 
>> I hope I've fixed it.
> 
> Ryan:
> 
> Sorry. Still hangs.
> 
> --->  Computing dependencies for gimp2
> The following dependencies will be installed:  
> gegl
> glib-networking
> poly2tri-c
> Continue? [Y/n]:  --->  Fetching archive for poly2tri-c
> --->  Attempting to fetch poly2tri-c-0.1.0_0.darwin_22.arm64.tbz2 from 
> https://packages.macports.org/poly2tri-c
> --->  Attempting to fetch poly2tri-c-0.1.0_0.darwin_22.arm64.tbz2 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/poly2tri-c
> --->  Attempting to fetch poly2tri-c-0.1.0_0.darwin_22.arm64.tbz2 from 
> http://mirror.fcix.net/macports/packages/poly2tri-c
> --->  Applying patches to poly2tri-c

Please run:

sudo port clean poly2tri-c
sudo port selfupdate

Then try again. If it fails again, please attach the new main.log file to the 
ticket.

Re: poly2tri-c fails to install on Ventura 13.2 (with M1 chip)

[Ryan Schmidt]

On Feb 5, 2023, at 16:01, Alan Needleman wrote:
> 
> I updated to Ventura 13.2 from Monterey 12..6.3 and migrated my Macports 
> installation. All ports installed and seem to be working fine except for 
> poly2tri-c-0.1.0_0.darwin_22.arm64. It downloads and then gets to “installing 
> patches”  and hangs so I kill the process (I haven’t seen any error message 
> in the log file).

This was filed here:

https://trac.macports.org/ticket/66851

I hope I've fixed it.


> On the Macports website listing for poly2tri-c  there is a “?” for Ventura 
> (arm64) so this may be a known issue.

The arm64 Ventura build machine has not yet been set up so there will be a "?" 
on the ports web site for all ports on arm64 Ventura.

Re: mac and ssl/openssl

[Ryan Schmidt]

On Feb 5, 2023, at 16:08, Riccardo Mottola wrote:

> Old versions of macs which I use, like 10.4 up to 10.7 have openssl and ssl.h
> 
> I tested that 10.13 doesn't have, so GNUMail doesn't compile.
> 
> Did Mac switch to a different ssl version and/or changed the location of it? 
> with which version?
> Do you have experience supporting it?
> I'd like to keep GNUMail working on vintage macs, but also support newer ones.

https://web.archive.org/web/20221129062249/http://lists.apple.com/archives/macnetworkprog/2015/Jun/msg00025.html

Re: Getting errors when upgrading to Ventura

[Ryan Schmidt]

On Feb 5, 2023, at 16:25, Mannucci, Anthony J wrote:

> I recently upgraded to Ventura and I am following the migration procedure.
>  
> I updated Xcode etc. When restoring ports, I am getting errors associated 
> with perl and llvm. Should I file a bug report?
>  
> Here is a list of error messages before the process quit:
> 223:Error: Failed to configure perl5.16: configure failure: command execution 
> failed
> 224:Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.16/main.log
>  for details.
> 231:Error: Failed to configure perl5.22: configure failure: command execution 
> failed
> 232:Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.22/main.log
>  for details.
> 239:Error: Failed to configure perl5.24: configure failure: command execution 
> failed
> 240:Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.24/main.log
>  for details.
> 247:Error: Failed to configure perl5.26: configure failure: command execution 
> failed
> 248:Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.26/main.log
>  for details.
> 626:Error: Failed to configure llvm-3.3: consult 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.3/llvm-3.3/work/build/config.log
> 627:Error: Failed to configure llvm-3.3: configure failure: command execution 
> failed
> 628:Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.3/llvm-3.3/main.log
>  for details.
> 1024:Error: Failed to build cctools: command execution failed
> 1025:Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cctools/cctools/main.log
>  for details.
> 1026:Error: Requested variants "+xcode" do not match those the build was 
> started with: "+llvm10".
> 1027:Error: Please use the same variants again, or run 'port clean cctools' 
> first to remove the existing partially completed build.
>  
> Errors associated w/ perl seem to be like:
> 1080::debug:archivefetch Fetching archive failed: The requested URL returned 
> error: 404
> 1082::debug:archivefetch Fetching archive failed: The requested URL returned 
> error: 404
> 1084::debug:archivefetch Fetching archive failed: The requested URL returned 
> error: 404
> 1172::error:configure Failed to configure perl5.26: configure failure: 
> command execution failed
> 1173::debug:configure Error code: NONE
> 1177::error:configure See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_perl5/perl5.26/main.log
>  for details.
>  
> Errors associated with llvm are like:
> 240::debug:archivefetch Fetching archive failed: The requested URL returned 
> error: 404
> 242::debug:archivefetch Fetching archive failed: The requested URL returned 
> error: 404
> 244::debug:archivefetch Fetching archive failed: The requested URL returned 
> error: 404

Each failure will need individual investigation by reading the main.log file.

404 errors when fetching archives are not a problem. When MacPorts cannot fetch 
an archive, it builds from source. If *that* fails, *that's* a problem.

Some of the ports you mentioned, like perl5.16 and llvm-3.3, are ancient and 
may not be buildable on Ventura, or even if they build they may have bugs that 
were fixed a long, long time ago. Use newer versions of these ports, for 
example perl5.34 and llvm-15.

The cctools failure is explained in the error message. Clean the port and try 
again. Probably you want to run "sudo port install cctools" without specifying 
any variant, to let MacPorts pick the best variant for your system, if indeed 
you need to install the port at all. If you don't know that you need the port, 
don't install it. MacPorts will install it if it's needed as a dependency later.

You should probably read through the list of ports in myports.txt and remove 
any that you do not explicitly want rather than just reinstalling all the ports 
you had on your old system, some of which may have at one point been needed as 
a dependency of something but which aren't anymore.

Re: Install on Ventura 14.2

[Ryan Schmidt]

On Feb 2, 2023, at 20:58, Joshua Root wrote:
> 
>> 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.

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.

If the installer takes a long time and you want to know what it is doing you 
can choose Installer Log from the menu and then change the drop-down menu from 
showing only errors to showing everything.

If your network connection to our primary public server rsync.macports.org (in 
Germany) is slow you can configure MacPorts to use a closer server from among 
these choices:

https://trac.macports.org/wiki/Mirrors

Re: port install of xemacs fails due to failure to install Xaw3d

[Ryan Schmidt]

On Jan 31, 2023, at 01:21, Kenneth Wolcott wrote:
> 
>  I get a different error now when trying to install xemacs:
> 
> *** PANIC *** Configure tests are not working - compiler is broken.
> *** PANIC *** Please examine config.log for compilation errors.

The preceding line was:

:info:configure checking size of short... 0

The config.log says that test failed because:

configure:4511: checking size of short
configure:4525: /usr/bin/clang -o conftest -pipe -Os -std=gnu89 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -arch arm64 
-I/opt/local/include 
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk  
-I/opt/local/include  -L/opt/local/lib -Wl,-headerpad_max_install_names 
-Wl,-no_pie 
-Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -Xlinker 
-arch -Xlinker arm64  -L/opt/local/lib conftest.c   1>&5
configure:4519:11: error: implicitly declaring library function 'exit' with 
type 'void (int) __attribute__((noreturn))' 
[-Werror,-Wimplicit-function-declaration]
  if (!f) exit(1);
  ^
configure:4519:11: note: include the header  or explicitly provide a 
declaration for 'exit'

This is https://trac.macports.org/ticket/61383.

Re: port install of xemacs fails due to failure to install Xaw3d

[Ryan Schmidt]

On Nov 20, 2022, at 23:39, Kenneth Wolcott wrote:
> 
> Here's a fresh install log for Xaw3d (attached compressed)
> 
> On Sun, Nov 20, 2022 at 6:51 PM Kenneth Wolcott
>  wrote:
>> 
>> Hi Ryan;
>> 
>> /opt/local/bin/xz --version
>> xz (XZ Utils) 5.2.7
>> liblzma 5.2.7
>> 
>> On Sun, Nov 20, 2022 at 4:51 PM Ryan Schmidt  wrote:
>>> 
>>> On Nov 14, 2022, at 16:22, Kenneth Wolcott wrote:
>>> 
>>>> This appears to be a common problem with several MacPorts install attempts.
>>>> 
>>>> How do I install xemacs?
>>>> 
>>>> excerpt...
>>>> --->  Extracting Xaw3d
>>>> --->  Extracting libXaw3d-1.6.4.tar.xz
>>>> Executing:  cd 
>>>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_Xaw3d/Xaw3d/work"
>>>> && /opt/local/bin/xz -dc
>>>> '/opt/local/var/macports/distfiles/Xaw3d/libXaw3d-1.6.4.tar.xz' |
>>>> /usr/bin/tar -xf -
>>>> Command failed:  cd
>>>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_Xaw3d/Xaw3d/work"
>>>> && /opt/local/bin/xz -dc
>>>> '/opt/local/var/macports/distfiles/Xaw3d/libXaw3d-1.6.4.tar.xz' |
>>>> /usr/bin/tar -xf -
>>>> Killed by signal: 9
>>>> Error: Failed to extract Xaw3d: command execution failed
>>> 
>>> I'm not sure what that would fail at that point.
>>> 
>>> Does the /opt/local/bin/xz command work otherwise? Does "/opt/local/bin/xz 
>>> --version" give a sensible answer for example?
>>> 
> 

Failure to extract in trace mode on Ventura is:

https://trac.macports.org/ticket/66358

Workaround: don't use trace mode

Re: invoking evince generates a dbus warning regarding launchd; how to fix this?

[Ryan Schmidt]

On Nov 21, 2022, at 00:21, Kenneth Wolcott wrote:

> invoking evince generates a dbus warning regarding launchd; how to fix this?
> 
> dbus[28817]: Dynamic session lookup supported but failed: launchd did
> not provide a socket path, verify that
> org.freedesktop.dbus-session.plist is loaded!

Run the command:

port notes dbus

and follow the instructions it prints.

Re: While trying to install lilypond, libuninameslist failed; install libuninameslist failed

[Ryan Schmidt]

On Nov 21, 2022, at 11:02, Kenneth Wolcott wrote:
> 
> While trying to install lilypond, libuninameslist failed; install
> libuninameslist failed
> 
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libuninameslist/libuninameslist/work"
> && /usr/bin/gzip -dc
> '/opt/local/var/macports/distfiles/libuninameslist/libuninameslist-20180701.tar.gz'
> | /usr/bin/tar -xf -
> Command failed:  cd
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_libuninameslist/libuninameslist/work"
> && /usr/bin/gzip -dc
> '/opt/local/var/macports/distfiles/libuninameslist/libuninameslist-20180701.tar.gz'
> | /usr/bin/tar -xf -
> Killed by signal: 9
> Error: Failed to extract libuninameslist: command execution failed
> 
> Compressed log file attached.
> 
> Thanks,
> Ken Wolcott
> 

The log shows this was on Ventura, so this bug is:

https://trac.macports.org/ticket/66358

Workaround: don't use trace mode.

Re: gv apparently silently fails to install properly

[Ryan Schmidt]

On Dec 19, 2022, at 15:55, Kenneth Wolcott wrote:
> 
>  I recently uninstalled and re-installed gv.
> 
>  There were no errors that I saw during the install (source code
> build forced with "-s").
> 
> Yet, when I try to invoke gv, I get a what looks to be a linkage error:
> 
> /opt/local/bin/gv -v dyld[7999]: symbol not found in flat namespace '_yylex''

https://trac.macports.org/ticket/66211

Re: Issue with installing port

[Ryan Schmidt]

On Jan 26, 2023, at 09:07, Will Senn wrote:

> On 1/26/23 1:43 AM, Joshua Root wrote:
>>> I'm trying to get pandoc to install.
>> The ticket for this is , FWIW.
> 
> I promise you I did search :). Thanks for the link though, it confirms it's 
> not just me!
> 
> `sudo port install pandoc -stack` works for now.
> 
> Suppose it didn't though... would I not be able to get the working version 
> that previously existed at all?

https://trac.macports.org/wiki/howto/InstallingOlderPort

> or is this an actual bug  in the recipe for 10.x's that somebody might fix 
> (it not working on MacOS < 11). I'm kind of clueless as to how macports works 
> behind the scenes because it has just pretty much worked for me over the 
> years without my having to worry about it.

The Portfile was deliberately programmed to do something different on macOS 
10.x than on macOS 11 and later. Based on the build failures, that appears to 
have been the wrong thing to do, and the Portfile has since been changed to no 
longer do that.

> I remember somebody way back when telling me that over time, things might 
> eventually stop working, but I thought that was bitrot or something, not this 
> kind of thing.

Most MacPorts contributors test on the latest or at least a recent macOS 
version. Most software developers also upgrade their systems to the latest or 
recent versions. Thus, as time goes on and ports are updated to new versions, 
it becomes increasingly likely that some change is introduced in some OS 
version and that some software starts depending on that change, and that users 
who remain on old OS versions are more likely to experience problems as a 
result. Whenever you find a problem, report it and hopefully someone can figure 
out how to fix it.

Re: What is "ghc" and why was it installed?

[Ryan Schmidt]

On Jan 18, 2023, at 17:31, Clemens Lang wrote:
> 
> On Wed, Jan 18, 2023 at 04:08:25AM +, Fielding, Eric J (US 329A) via 
> macports-users wrote:
>> I was running “port selfupdate” and “port upgrade outdated” for the
>> first time in a while, and I noticed that my Intel MacBook Pro was
>> spending almost an hour compiling a port called “ghc” that I don’t
>> remember seeing before and I am sure I did not request. Is this part
>> of something else that was added recently that is now a dependency of
>> some other port?
> 
> The most common ports that depend on GHC are pandoc and shellcheck. My
> guess is that you're on Monterey, where pandoc currently fails to build
> because GHC fails to build.
> 
> See https://ports.macports.org/port/pandoc/details/, which shows the
> failure on the right side. The build of pandoc on our buildbot [1]
> failed, so the buildbot did not produce a pre-compiled binary.
> Previously, you likely downloaded the precompiled binary and avoided the
> GHC dependency.
> 
> The build of GHC that previously failed is [2] (WARNING, that's an 8 MiB
> text file over a slow connection). The first error in that build is
> 
>  x 
> ./opt/local/lib/ghc-9.4.4/lib/x86_64-osx-ghc-9.4.4/libHSCabal-syntax-3.8.1.0-ghc9.4.4.dylib:
>  Cannot restore xattr: com.apple.ResourceFork at 592512 pos 65536 bytes: No 
> space left on device
> 
> i.e. our build machine ran out of disk space. I'm adding Ryan to Cc, who
> maintains our build infrastructure. Maybe there's some regular cleanup
> we can run.
> 
> Meanwhile, I'll see if I can re-trigger the build of GHC and eventually
> pandoc to fix this.
> 
> 
> [1]: 
> https://build.macports.org/builders/ports-12_x86_64-builder/builds/55400/steps/install-dependencies/logs/stdio
> [2]: 
> https://build.macports.org/builders/ports-12_x86_64-builder/builds/54550/steps/install-port/logs/stdio/text

The re-attempt that you triggered completed successfully.

The machine has 15 GB available usually. This is less than I would like but 
there isn't anything taking up unnecessary space. Xcode just continues its 
yearly quest to use up all disk space everywhere. I should probably have 
allocated a bit more disk space to this VM when I set it up but I didn't.

Re: Macports won't uninstall

[Ryan Schmidt]

On Jan 23, 2023, at 12:43, Isabelle Dolan wrote:

> I tried running uninstall and got this:
> > Running command: /opt/local/bin/port -fp uninstall installed
> > Error: No ports matched the given expression
> 
> I am running a script that uninstalls macports using 'Running command: 
> /opt/local/bin/port -fp uninstall installed' and then reinstall the proper 
> configuration. Since the script can't uninstall it, I tried to follow the 
> instructions in section 2.4 to uninstall fully. Even after doing that, I 
> still get the same error. 
> 
> I really need to get past this to be able to finish running the script.
> 
> Any suggestions? 
> 
> Running command: /opt/local/bin/port -fp uninstall installed
> Error: No ports matched the given expression

In this context, this error means "no ports are installed". So you can proceed 
to the next step of uninstalling MacPorts.

Re: Install/uninstall Direwolf program errors

[Ryan Schmidt]

On Jan 3, 2023, at 21:39, Larrie Deardurff wrote:
> 
> I am running OS 13.1 on an intel iMac.  I installed the program “Direwolf” 
> using Macports, following the intstruction listed here 
> (https://ports.macports.org/port/direwolf/).  
> 
> I was having some problems with Direwolf and realized that between the 
> initial install of Macports and direwolf I had upgraded the OS from 12 to 13 
> - and error message I got from Macports suggested to run the migration 
> procedure for Macports.  I did that, installing the version for OS 13.  All 
> seemed to go without issue.
> 
> I decided to upgrade direwolf with sudo port upgrade direwolf and Macports 
> reports it is not installed.  (But it’s there, as typing direwolf in the 
> terminal starts the program).
> 
> Attempted to re-install direwolf - get error “Failed to build direwolf:  
> command execution failed.
> 
> Here is the output of the log file:
> 
> :error:build Failed to build direwolf: command execution failed
> :debug:build Error code: CHILDSTATUS 24328 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 8)
> :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_science_direwolf/direwolf/main.log
>  for details.
> 
> I was unable to find a definition of the CHILDSTATUS 24328 2 error code.  
> 
> Questions:   1.  Why does macports not see the earlier installation of 
> Direwolf?

It should. I cannot explain why for you it does not.

You said you followed the migration instructions. Part of those instructions 
are to uninstall all installed ports. If you did this, that would explain why 
direwolf is now not installed. However, that would not explain why you are 
still able to use the direwolf program; that suggests that it is still 
installed.


>2.  What would cause the above error?

You haven't shown us the relevant error message. Filing a ticket in the issue 
tracker and attaching the entire main.log file is the best way to report bugs.


>3.  Under macports, what is the command to remove a 
> program?

sudo port uninstall portname

replacing "portname" with the name of the port you want to uninstall.

Re: ninja: build stopped: subcommand failed. Error: Failed to build gegl: command execution failed

[Ryan Schmidt]

On Jan 12, 2023, at 20:23, chilli.names...@gmail.com wrote:

> What's strange is port outdated doesn't show anything, so I expect these 
> ports are broken and my install doesn't know it. I bet it has something to do 
> with port reclaim running when I tried to selfupdate. I deleted all the build 
> directories out of habit. 
> 
> gegl @0.4.40_0+quartz+vala (active)
> 
> but ninja is not installed for some reason :/
> And idk what is using these ports.
> 
>> ninja: build stopped: subcommand failed.
>> Command failed:  cd 
>> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_gegl/gegl/work/build"
>>  && /opt/local/bin/ninja -j8 -v
>> Exit code: 1
>> Error: Failed to build gegl: command execution failed
>> Error: See 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_gegl/gegl/main.log
>>  for details.
>> Error: rev-upgrade failed: Error rebuilding gegl
>> Error: Follow https://guide.macports.org/#project.tickets if you believe 
>> there is a bug.
> 
> 
> 

The ninja port is installed and building gegl is using ninja.

The build fails because:

:info:build ../gegl-0.4.40/operations/external/raw-load.c:117:29: error: no 
member named 'shot_select' in 'libraw_output_params_t'
:info:build   p->LibRaw->params.shot_select = o->image_num;
:info:build   ~ ^
:info:build 1 error generated.

This is the ticket for this issue:

https://trac.macports.org/ticket/7

It has been fixed. Run "sudo port selfupdate" to receive the fix.

Re: How use py-pip?

[Ryan Schmidt]

On Nov 30, 2022, at 14:42, Murray Eisenberg wrote:

> The python package I’m trying to install is pyobjc, for which no separte 
> MacPorts port seems to exist.

PyObjC is available in the subports of the py-pyobjc port.

Re: Emacs.app does not run after upgrade to macOS 13.0.1

[Ryan Schmidt]

On Nov 10, 2022, at 11:56, Artemio González López wrote:
> 
> After installing the 13.0.1 update on my M1 MacBook Pro I emacs.app crashes 
> on launch. Apparently, the problem is that it cannot find a library:
> 
> Crashed Thread:0
> 
> Exception Type:EXC_CRASH (SIGABRT)
> Exception Codes:   0x, 0x
> 
> Termination Reason:Namespace DYLD, Code 1 Library missing
> Library not loaded: /opt/local/lib/libicui18n.71.dylib
> Referenced from: <45F9A0DF-B06D-34C8-946F-88FFA574E722> 
> /opt/local/lib/libxml2.2.dylib
> Reason: tried: '/opt/local/lib/libicui18n.71.dylib' (no such file), 
> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libicui18n.71.dylib' (no 
> such file), '/opt/local/lib/libicui18n.71.dylib' (no such file), 
> '/usr/local/lib/libicui18n.71.dylib' (no such file), 
> '/usr/lib/libicui18n.71.dylib' (no such file, not in dyld cache)
> (terminated at launch; ignore backtrace)


icu was updated from version 71.x to 72.x on November 5. Everything that links 
with icu therefore has to be rebuilt.

It is possible that a simple "sudo port upgrade outdated" will not upgrade 
everything in the correct order, and you may have to initiate individual 
upgrades by name. For example, in this case, having encountered an error about 
libxml2 still being linked to icu 71, you should "sudo port upgrade libxml2" 
first, then try again. If you find another build error about another thing that 
is still linked with icu 71, upgrade that thing, then retry again, etc.

Re: Emacs.app does not run after upgrade to macOS 13.0.1

[Ryan Schmidt]

On Nov 11, 2022, at 13:34, Artemio González López wrote:
> 
> I’m happy to report that after upgrading my ports —which took several days, 
> because for some reason gcc12 had to be compiled from scratch— Emacs now 
> works perfectly.

You're on macOS 13 so everything will have to be compiled from source because I 
have not yet set up the automated build machines for macOS 13.

Re: port install of xemacs fails due to failure to install Xaw3d

[Ryan Schmidt]

On Nov 14, 2022, at 16:22, Kenneth Wolcott wrote:

>  This appears to be a common problem with several MacPorts install attempts.
> 
>  How do I install xemacs?
> 
> excerpt...
> --->  Extracting Xaw3d
> --->  Extracting libXaw3d-1.6.4.tar.xz
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_Xaw3d/Xaw3d/work"
> && /opt/local/bin/xz -dc
> '/opt/local/var/macports/distfiles/Xaw3d/libXaw3d-1.6.4.tar.xz' |
> /usr/bin/tar -xf -
> Command failed:  cd
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_x11_Xaw3d/Xaw3d/work"
> && /opt/local/bin/xz -dc
> '/opt/local/var/macports/distfiles/Xaw3d/libXaw3d-1.6.4.tar.xz' |
> /usr/bin/tar -xf -
> Killed by signal: 9
> Error: Failed to extract Xaw3d: command execution failed

I'm not sure what that would fail at that point.

Does the /opt/local/bin/xz command work otherwise? Does "/opt/local/bin/xz 
--version" give a sensible answer for example?

Re: Where is port command documented?

[Ryan Schmidt]

On Nov 14, 2022, at 03:14, Lukas Oberhuber wrote:
> 
> I was wondering where the port command flags are documented. For example, I'm 
> trying to uninstall a port in a script, but when two versions of the port are 
> installed, it interactively asks which I want to uninstall.
> 
> The following versions of gimp3 are currently installed:
>  1) gimp3 @2.99.14_0+debugoptimized+quartz+vala
>  2) gimp3 @2.99.13_1+debugoptimized+quartz+vala (active)
> Enter option(s) [1-2/all]: 
> 
> This kills my script. What I can't tell is if port -N uninstall gimp3 exists, 
> or if that is only for port install.
> 
> And before you say: "try it", it's on a ci system so a little harder to try, 
> and really, I want a way to understand all the available flags.
> 
> And finally, there is no error message when a flag is used in the wrong 
> place, so that makes trial and error even harder. Example port install -N 
> gimp3 does not apply the flag but doesn't error.

The port(1) manpage was already mentioned, but a web version of it is also 
available at:

https://man.macports.org/port.1.html

Single-dash single-letter flags like "-N" are global and apply to all commands 
and go after "port" and before the command verb (e.g. "sudo port -N install 
foo" not "sudo port install -N foo"). Double-dash multi-letter flags are 
specific to the command verb and go after the command verb and before any 
subsequent list of ports (like "--no-sync" is specific to the "selfupdate" verb 
and is used as "sudo port selfupdate --no-sync" not "sudo port --no-sync 
selfupdate").

If you have multiple versions of a port installed and try to uninstall just by 
name, it prompts interactively to ask which one(s). If you turn off 
interactivity with "-N", the uninstall will fail since it doesn't know which 
one to uninstall. If you want to uninstall all installed versions of a 
particular port, you could use e.g. sudo port -N uninstall installed and 
name:'^gimp3$'

Re: how to move "Python Launcher" away from /Application folder?

[Ryan Schmidt]

On Nov 9, 2022, at 17:57, supervisitor wrote:

> ... ups, this I have probably overlooked. (have made the installation from 
> source).
> 
> But before I now uninstall everything to perform a reinstall, some further 
> questions:
> 
> Can I do an installation with parameter "--with-applications-dir" carefree 
> over the existing installation... without losing the information about 
> installed apps, e.g. inside "registry.db"?
> The documentation for upgrading a source installation is described as follows 
> in the documentation:
>   MacPorts Guide, Chapter: 2.3:
>   "To upgrade a copy of MacPorts that was installed from source to the 
> newer release of the source code, simply repeat the source install with the 
> newer version of the MacPorts source code."
> But does this also apply if I specify an additional parameter like 
> "--with-applications-dir"?
> 
> Or can I change the path afterwards in configuration file(s), e.g. 
> '/opt/local/etc/macports/macports.conf:applications_dir
> /Applications/MacPorts'?
> (of course after a 'sudo mv /Applications/MacPorts /opt/local/.')

I think either is fine: Either reconfigure with a different 
--with-applications-dir or edit applications_dir in macports.conf. Neither will 
affect your installed ports. Any ports you already have installed that put 
files in /Applications/MacPorts will continue to believe that that's where 
their files are and you should not manually move them. After you change the 
setting, you should rebuild those ports (e.g. sudo port -n upgrade --force 
python310).

The pre-compiled archives we build on our servers are tailored to certain 
default MacPorts settings, including the prefix, applications_dir, 
frameworks_dir, and others. If you change these settings, you will not receive 
any pre-compiled archives and will have to compile every port from source when 
you install it. This is usually undesirable (people usually like receiving an 
archive in seconds instead of waiting minutes or hours for a port to compile) 
so I recommend you do not change these settings.

Re: Error installing Kampose

[Ryan Schmidt]

On Oct 28, 2022, at 12:23, James McManus wrote:

> However, I am still not able to install Kompose. I'm still getting the not a 
> git repository error message:
> 
> :info:build Executing:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_kompose/kompose/work/gopath/src/github.com/kubernetes/kompose"
>  && make -j8 -w bin
> :debug:build system:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_kompose/kompose/work/gopath/src/github.com/kubernetes/kompose"
>  && make -j8 -w bin
> :info:build fatal: not a git repository (or any of the parent directories): 
> .git
> :info:build make: Entering directory 
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_kompose/kompose/work/gopath/src/github.com/kubernetes/kompose'
> 
> The directory path listed above does exist.

But presumably the directory is not a git repository. And that may be fine. I 
would ignore this "fatal" error and look for the next error after this.


> The I'm also getting a build error:
> 
> :info:build 
> ../../../../pkg/mod/golang.org/x/sys@v0.0.0-20201029080932-201ba4db2418/unix/zsyscall_darwin_amd64.go:121:3:
>  too many errors

The relevant error will be before this line, possibly significantly before. 
Usually the relevant error is the first error in the extract or patch or 
configure or build or destroot phase, except that in this case I think you can 
ignore the message about not being a git repository since, if that were 
required, the port would have been programmed to accomplish that.


On Oct 28, 2022, at 16:25, James McManus wrote:

> The first errors in the log 404 errors:
> 
> :msg:archivefetch --->  Fetching archive for kompose
> :debug:archivefetch Executing org.macports.archivefetch (kompose)
> :debug:archivefetch euid/egid changed to: 0/0
> :debug:archivefetch chowned /opt/local/var/macports/incoming to macports
> :debug:archivefetch euid/egid changed to: 503/501
> :info:archivefetch --->  kompose-1.24.0_0.darwin_22.x86_64.tbz2 doesn't seem 
> to exist in /opt/local/var/macports/incoming/verified
> :msg:archivefetch --->  Attempting to fetch 
> kompose-1.24.0_0.darwin_22.x86_64.tbz2 from 
> https://packages.macports.org/kompose
> :debug:archivefetch Fetching archive failed: The requested URL returned 
> error: 404

You can ignore archive fetch failures. They indicate that a pre-compiled 
archive was not found. No problem; it will be compiled from source on your 
system. We have not created any pre-compiled archives for macOS Ventura yet.


As you can see it's not always straightforward to determine what the relevant 
error is, so I recommend when you encounter a port that doesn't install you 
just file a bug report in our issue tracker and attach the log, and someone 
else can look at the log and determine what the problem is.

Re: macports-users Digest, Vol 194, Issue 22

[Ryan Schmidt]

On Oct 29, 2022, at 07:50, Artemio González López wrote:
> 
> Error: Failed to activate py310-jupyter: Image error: 
> /opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/__pycache__/jupyter.cpython-310.pyc
>  is being used by the active py310-jupyter_core port.  Please deactivate this 
> port first, or use 'port -f activate py310-jupyter' to force the activation.
> 
> Should I deactivate py310-jupyter_core, activate py310-jupyter, and activate 
> py310-jupyter_core, or is it better to just force activation of py310-jupyter 
> … or none of the above?

Force-activating ports is not recommended.

You should probably wait for the maintainer of the port to resolve the 
conflict, which I see you have reported at 
https://trac.macports.org/ticket/66124. Or anyone else can feel free to solve 
it and submit a pull request.

Re: Texmaker installation failed due to inability to build qt5 web engine

[Ryan Schmidt]

On Nov 4, 2022, at 07:03, Chris Jones wrote:

> Just on this point, if you don't want to have to build everything from 
> source, then you should not update your OS before MacPorts has deployed 
> buildbots for the new OS. You can check this at e.g.
> 
> https://build.macports.org/waterfall
> 
> and yes we do not yet have macOS13 in place. Ryan might be able to give an 
> idea of a timeline for this.

I can't give you any timeline yet.

Re: Libomp notes

[Ryan Schmidt]

On Nov 4, 2022, at 11:49, John Wiggins wrote:

> I am running macOS Monterey 12.6.1 and updated Xcode and CLT to 14.1.
> When I “upgrade outdate” I get note concerning libomp:
> 
> …
>> --->  Some of the ports you installed have notes:
>>  libomp has the following notes:
>> To use this OpenMP library:
>> * For clang-3.8+, or clang-3.7 with +openmp variant:
>>add "-fopenmp" during compilation / linking.
>> * For clang-3.7 without +openmp variant, use:
>>"-I/opt/local/include/libomp -L/opt/local/lib/libomp -fopenmp"
>>  libpsl has the following notes:
>> libpsl API documentation is provided by the port 'libpsl-docs’.
> 
> 
> There any action required of me? 

The note is advising you how to use libomp in your own projects. If you aren't 
using libomp in your own projects you can disregard the message.

Re: iInstall denemo failed due to failure to configure qt5-qtbase

[Ryan Schmidt]

On Nov 1, 2022, at 17:46, Kenneth Wolcott wrote:

> Very weird :-(
> 
> xcode-select -p
> /Library/Developer/CommandLineTools
> 
> I can't find an Xocde.app on my machine *anywhere* :-(
> 
> Guess I'll install yet again (SIGH*)
> 
> Doesn't Xcode.app automatically get installed in the correct place?
> How can I "nudge it" to install correctly?

If you install it from the Mac App Store, it goes in /Applications. If you 
download it from the Apple Developer web site, then you have to put it where 
you want it after you decompress it.

Re: iInstall denemo failed due to failure to configure qt5-qtbase

[Ryan Schmidt]

On Oct 29, 2022, at 18:56, Kenneth Wolcott wrote:
> 
> So I downloaded and installed the XCode RC 2 and CL Tools R2..
> 
> Then
> 
> port diagnose
> Error: The installed version of Xcode, none, is not supported by
> MacPorts. For your currently installed system, the following versions
> of Xcode are supported: 14.1
> LaTeX: xcode-select --install
> xcode-select: error: command line tools are already installed, use
> "Software Update" in System Settings to install updates
> 
> What does this mean?

It means MacPorts cannot find your Xcode.app.

Where is it? Is it at /Applications/Xcode.app?

What does "xcode-select -p" print? Is it 
"/Applications/Xcode.app/Contents/Developer"? If not, run "sudo xcode-select -s 
/Applications/Xcode.app/Contents/Developer" to set it properly. (Replace 
"/Applications/Xcode.app" with the actual path to your Xcode.app if it's 
somewhere else.)

Re: Catelina xcode

[Ryan Schmidt]

On Oct 11, 2022, at 22:46, James Linder wrote:

> My wife’s machine is Catelina (and Ends at Big Sur). It has, and I/She uses 
> lots of ports and IIRC we have used Qt before, but when I try to build 
> something I get the XCode license dialog. No worries, accept. "Something is 
> wrong see the log”
> The something wrong turn out to be Certificate Expired.
> After spelunking I got an Xcode for catelina. Install. "Something is wrong 
> see the log” Again Certificate Expired.
> 
> OK I’m starting to fumble. Setting her date back for a build is like a lead 
> balloon.
> A VM with no internet sccess ?
> 
> Any body able to guide me please?

Can you show the exact error message from the log?

You shouldn't have any trouble installing a compatible version of Xcode on 
Catalina, or for that matter on any other OS version, and you shouldn't need to 
change your computer's date.

The list of compatible Xcode versions for Catalina is at:

https://trac.macports.org/wiki/XcodeVersionInfo#macOS10.15

Don't forget to install the matching version of the Xcode command line tools.

Re: Aubio fails to install as a prerequisite for Denemo

[Ryan Schmidt]

On Oct 27, 2022, at 12:01, Kenneth Wolcott wrote:
> 
> I added a symlink:
> 
> sudo ln -s /opt/local/bin/python3.10 /opt/local/bin/python
> 
>  The aubio app now installs successfully.

Great, I'm glad that worked. That confirms that the port has a bug that needs 
to be fixed. Ports must not require users to do such things to build.

FYI, you can use `sudo port select python` to manage that symlink for you.

Re: Permissions issue detected on the tarballs/base file during upgrade to MacPorts 2.8.0

[Ryan Schmidt]

On Oct 21, 2022, at 02:54, Olaf Sulla wrote:

> Regarding the default UID and GID:
> 
> - The GID, as you mention, already exists on the system via virtue of a 
> previous install of postgreSQL packages.
> 
> - The UID 500 does not pre-exist.
> 
> The latter might be the problem because the parent folder has the permissions 
> of root:wheel. With there being no account with the UID of 500 existing on 
> the system, it is not listed in wheel and so this may cause sudo to fail.

I'm not certain how to respond to this, other than to say that our server 
configuration has been this way since late 2016 and we have not seen these 
permissions errors until the release of MacPorts 2.8.0 just now, and then only 
on Catalina and later, which makes me think they are not connected to the 
UID/GID.

Re: Gnome aisleriot solitaire

[Ryan Schmidt]

On Oct 21, 2022, at 03:23, John Batistic wrote:

> macOS Monterey
> 
> I wish to install Gnome Aisleriot (and just realised that it is an anagram of 
> Solitaire)
> But need assistance in making it happen.
> 
> I have;
> Successfully installed MacPorts, Gnome and Gnome Desktop, presuming that I 
> need these.
> Searched the available ports with zero results
> 
> I  don’t have enough information/knowledge to go any further.
> 
> Are ports from any other flavours of BSD compatible?

No. The structure of MacPorts Portfiles is unique, not shared with any other 
package manager or ports system. MacPorts was inspired by FreeBSD but does not 
share any code with it.

If you wish to attempt to create a Portfile, instructions are in the MacPorts 
Guide. If you just wish to register your desire for a new port to be created by 
someone, you can do that by filing a ticket in the issue tracker and someone 
might eventually get around to it.

Re: Permissions issue detected on the tarballs/base file during upgrade to MacPorts 2.8.0

[Ryan Schmidt]

On Oct 20, 2022, at 10:11, Olaf Sulla wrote:

> I installed the update to MacPorts 2.8.0 earlier today on a Mac Mini A1 
> running Monterey 12.6.
> 
> During the install the following error was reported:
> 
> NFO: Syncing port data and updating port-base ...
> Password:
> --->  Updating MacPorts base sources using rsync
> MacPorts base version 2.7.2 installed,
> MacPorts base version 2.8.0 downloaded.
> --->  Updating the ports tree
> --->  MacPorts base is outdated, installing new version 2.8.0
> Installing new MacPorts release in /opt/local as root:wheel; permissions 0755
> 
> Error: Couldn't change permissions of the MacPorts sources at 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base
>  to root: child killed: kill signal
> Please run `port -v selfupdate' for details.
> Error: /opt/local/bin/port: port selfupdate failed: Couldn't change 
> permissions of the MacPorts sources at 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/base
>  to root: child killed: kill signal
> ERROR: Self update failed with exit code: 1
> ERROR: MacPorts sync failed
> 
> I re-ran the self update with the ‘-v’ option but no error was reported.

We also saw these errors on our automated build system, e.g.:

https://build.macports.org/builders/ports-11_x86_64-watcher/builds/24366/steps/selfupdate/logs/stdio

And other users have reported the error too:

https://trac.macports.org/ticket/66031

So there does appear to be some problem that we need to fix.

After our automated build system encountered this error, MacPorts 2.8.0 was 
nevertheless installed and appeared to work normally, so you may be able to 
just ignore the error for now.


> I checked the folder permissions:
> 
> ls -la 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs  
> total 226484
> drwxr-xr-x 10 root wheel  320 Oct 20 11:50 .
> drwxr-xr-x  3 root wheel   96 Nov 29  2020 ..
> -rw-r--r--  1 root wheel 18098189 Oct 20 08:34 PortIndex
> -rw-r--r--  1 root wheel  512 Oct 20 08:56 PortIndex.rmd160
> drwxr-xr-x 30 root postgres   960 Oct 20 07:02 base
> -rw-r--r--  1 root wheel113716224 Oct 20 07:45 base.tar
> -rw-r--r--  1 root wheel  512 Oct 20 07:45 base.tar.rmd160
> drwxr-xr-x 62 root postgres  1984 Oct 20 11:50 ports
> -rw-r--r--  1 root wheel100087808 Oct 20 08:56 ports.tar
> -rw-r--r--  1 root wheel  512 Oct 20 08:56 ports.tar.rmd160
> 
> Group II:
> 
> drwxr-xr-x 30 0 505   960 Oct 20 07:02 base
> drwxr-xr-x 62 0 505  1984 Oct 20 11:50 ports
> 
> 
> The ‘postgres’ group is listed via dscl.
> 
> I was not expecting to see the group set to ‘postgres’ on these folders. 
> 
> Could you please advise if I should raise one or more tickets for this, and 
> could you confirm what permissions I should expect to find on these folders.

The files in the base.tar and ports.tar tarballs generated by our server are 
currently owned by uid 500 and gid 505 because those are the uid and gid of the 
process that runs on the server that generates the tarballs. What those uid and 
gid map to on each user's system will be different, so you may see different 
usernames and group names for those files on each system, or you may see the 
numbers 500 or 505 if you do not have those uids or gids assigned. On your 
system, gid 505 happens to have been assigned to postgres. This situation is 
untidy, but has not been a problem before. Ideally, to reduce confusion, I 
should change the server-side process that generates the tarballs so that the 
files are owned by a predictable user and group, such as the macports user and 
group, but I haven't done that yet. This will require either running the 
process as the macports user (which is untidy and may be impossible due to the 
deliberately limited capabilities of that user), running the process as root 
(which I had hoped to avoid because it gives that process unlimited 
capabilities), or using the fakeroot program (which I think will work).

Re: Aubio fails to install as a prerequisite for Denemo

[Ryan Schmidt]

On Oct 16, 2022, at 20:28, Kenneth Wolcott wrote:

> --->  Building aubio
> Executing:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_aubio/aubio/work/aubio-0.4.9"
> && /opt/local/bin/python2.7 ./waf build --verbose
> Waf: Entering directory
> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_audio_aubio/aubio/work/aubio-0.4.9/build'
> Sphinx manual: install aubio first
> [176/231] Compiling tests/create_tests_source.py
> 17:58:12 runner ' python ../tests/create_tests_source.py
> tests/44100Hz_44100f_sine441_stereo.wav '
> /bin/sh: python: command not found

Please file a bug report in the issue tracker.

Re: dead man page links?

[Ryan Schmidt]

On Oct 1, 2022, at 01:39, Richard L. Hamilton wrote:
> 
> Given a bunch of No such file or directory errors from man -k and/or 
> /usr/libexec/makewhatis, I looked a bit, and
> 
> /opt/local/share/man/man1/dot2gxl.1 is provided by: graphviz
> /opt/local/share/man/man1/fcat.1.gz is provided by: fsp
> /opt/local/share/man/man1/fcd.1.gz is provided by: fsp
> /opt/local/share/man/man1/fdu.1.gz is provided by: fsp
> /opt/local/share/man/man1/ffind.1.gz is provided by: fsp
> /opt/local/share/man/man1/fget.1.gz is provided by: fsp
> /opt/local/share/man/man1/fgrab.1.gz is provided by: fsp
> /opt/local/share/man/man1/fhost.1.gz is provided by: fsp
> /opt/local/share/man/man1/fls.1.gz is provided by: fsp
> /opt/local/share/man/man1/fmv.1.gz is provided by: fsp
> /opt/local/share/man/man1/fpro.1.gz is provided by: fsp
> /opt/local/share/man/man1/frm.1.gz is provided by: fsp
> /opt/local/share/man/man1/frmdir.1.gz is provided by: fsp
> /opt/local/share/man/man1/fsetup.1.gz is provided by: fsp
> /opt/local/share/man/man1/fstat.1.gz is provided by: fsp
> /opt/local/share/man/man1/gimp-console.1 is provided by: gimp2
> /opt/local/share/man/man1/xxh128sum.1 is provided by: xxhash
> /opt/local/share/man/man1/xxh32sum.1 is provided by: xxhash
> /opt/local/share/man/man1/xxh64sum.1 is provided by: xxhash
> 
> all turn out to be symlinks to nonexistent files. What’s up with that? I 
> certainly didn’t remove man pages manually.

Please file a separate bug report for each individual affected port, for which 
a bug report does not already exist, so that each issue can be investigated and 
fixed separately.

The bug report about graphviz for example is 
https://trac.macports.org/ticket/61288 so you don't need to file that one. I 
haven't checked if the others have bug reports already.

Re: Unable to build XV

[Ryan Schmidt]

On Sep 18, 2022, at 18:37, Dave Horsfall wrote:
> 
>:info:build xvjp2k.c:77:5: error: redefinition of 'jas_getdbglevel'
>:info:build int jas_getdbglevel(void) {return 0;}
>:info:build ^
>:info:build /opt/local/include/jasper/jas_debug.h:123:5: note: previous 
> definition is here
>:info:build int jas_getdbglevel(void)
>:info:build ^
>:info:build 1 error generated.
>:info:build make: *** [xvjp2k.o] Error 1
> 
> Anyone else seeing this before I lodge a bug report?

Yes absolutely please file bug reports in the issue tracker when there isn't 
already one. In this case, one has already been filed by now:

https://trac.macports.org/ticket/65864

Re: Cannot build DOSBOX

[Ryan Schmidt]

On Sep 18, 2022, at 23:39, Dave Horsfall wrote:

>--->  Computing dependencies for dosbox
>Error: Cannot install dosbox for the arch 'i386' because
>Error: its dependency libsdl does not build for the required arch by 
> default
>Error: and the configured universal_archs '' are not sufficient.
> 
> macports.conf:
> 
># Space-delimited list of CPU architectures to target when building
># universal. Defaults to "i386 ppc" on Mac OS X 10.5 and earlier,
># "x86_64 i386" on Mac OS X 10.6 through macOS 10.13, "x86_64" on
># macOS 10.14 and 10.15 (these SDKs are not universal), and
># "arm64 x86_64" on macOS 11 and later. Set an empty value to disable
># universal building.
>#universal_archsx86_64 i386
>universal_archs
> 
> Should I hardwire it to those?  I ain't likely to use PPC etc.

dosbox is only available for 32-bit (i386).

On your OS version, software builds 64-bit (x86_64) by default.

Therefore, anything that is 32-bit only and has dependencies must install those 
dependencies universal (32-bit and 64-bit) on your system.

You have disabled universal building by setting universal_archs to empty, 
therefore you cannot install dosbox.

If you want to allow universal builds, remove the line "universal_archs" from 
macports.conf to let the default value (x86_64 i386 on your system) take effect.

The compilers in Xcode on your OS version cannot compile for ppc so including 
ppc in universal_archs won't work.