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

2023-08-31 Thread 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

2023-08-31 Thread 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

2023-08-31 Thread 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

2023-08-31 Thread 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.