Re: py39-nbconvert fails to build on Catalina

[Ryan Schmidt]

On Sep 8, 2022, at 08:49, Artemio González López wrote:

> I got the following error when trying to build py39-nbconvert on a 2014 27” 
> iMac running the latest version of Catalina (10.15.7). The error I got (from 
> main.log) is the following:
> 
> :info:build Executing:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work/nbconvert-7.0.0"
>  && /opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 
> -m build --wheel --no-isolation --outdir 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work
>  
> :debug:build system:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work/nbconvert-7.0.0"
>  && /opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 
> -m build --wheel --no-isolation --outdir 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work
>  
> :info:build Failed to download css from 
> https://unpkg.com/@jupyterlab/nbconvert-css@3.1.11/style/index.css:  error [Errno 64] Host is down>
> :info:build Failed to download css from 
> https://unpkg.com/@jupyterlab/theme-light-extension@3.1.11/style/variables.css:
>  
> :info:build Failed to download css from 
> https://unpkg.com/@jupyterlab/theme-dark-extension@3.1.11/style/variables.css:
>  
> :info:build Failed to download css from 
> https://cdn.jupyter.org/notebook/5.4.0/style/style.min.css:  [Errno 64] Host is down>
> 
> This error happens a few more times after that, and the build aborts with the 
> following message:
> 
> :info:build raise OSError("Need CSS to proceed.")
> :info:build OSError: Need CSS to proceed.
> :info:build * Getting dependencies for wheel...
> :info:build * Building wheel...
> :info:build ERROR Backend subprocess exited when trying to invoke build_wheel
> :info:build Command failed:  cd 
> "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work/nbconvert-7.0.0"
>  && /opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 
> -m build --wheel --no-isolation --outdir 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work
>  
> :info:build Exit code: 1
> :error:build Failed to build py39-nbconvert: command execution failed
> :debug:build Error code: CHILDSTATUS 31665 1
> :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_python_py-nbconvert/py39-nbconvert/main.log
>  for details.
> 
> Any idea what the problem may be?

It evidently can't download something during the build that it needs.

(Ports should not download things during the build. This port evidently 
violates that.)

Please file a bug report in the issue tracker so that the maintainer of this 
port might look into this problem.

py39-nbconvert fails to build on Catalina

[Artemio González López via macports-users]

I got the following error when trying to build py39-nbconvert on a 2014 27” 
iMac running the latest version of Catalina (10.15.7). The error I got (from 
main.log) is the following:

:info:build Executing:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work/nbconvert-7.0.0"
 && /opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 
-m build --wheel --no-isolation --outdir 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work
 
:debug:build system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work/nbconvert-7.0.0"
 && /opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 
-m build --wheel --no-isolation --outdir 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work
 
:info:build Failed to download css from 
https://unpkg.com/@jupyterlab/nbconvert-css@3.1.11/style/index.css: 
<https://unpkg.com/@jupyterlab/nbconvert-css@3.1.11/style/index.css:> 
:info:build Failed to download css from 
https://unpkg.com/@jupyterlab/theme-light-extension@3.1.11/style/variables.css: 
<https://unpkg.com/@jupyterlab/theme-light-extension@3.1.11/style/variables.css:>
 
:info:build Failed to download css from 
https://unpkg.com/@jupyterlab/theme-dark-extension@3.1.11/style/variables.css: 
<https://unpkg.com/@jupyterlab/theme-dark-extension@3.1.11/style/variables.css:>
 
:info:build Failed to download css from 
https://cdn.jupyter.org/notebook/5.4.0/style/style.min.css: 
<https://cdn.jupyter.org/notebook/5.4.0/style/style.min.css:> 

This error happens a few more times after that, and the build aborts with the 
following message:

:info:build raise OSError("Need CSS to proceed.")
:info:build OSError: Need CSS to proceed.
:info:build * Getting dependencies for wheel...
:info:build * Building wheel...
:info:build ERROR Backend subprocess exited when trying to invoke build_wheel
:info:build Command failed:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work/nbconvert-7.0.0"
 && /opt/local/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 
-m build --wheel --no-isolation --outdir 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_python_py-nbconvert/py39-nbconvert/work
 
:info:build Exit code: 1
:error:build Failed to build py39-nbconvert: command execution failed
:debug:build Error code: CHILDSTATUS 31665 1
: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_python_py-nbconvert/py39-nbconvert/main.log
 for details.

Any idea what the problem may be?

Thanks in advance,

Artemio


Artemio Gonzalez Lopez
artem...@mac.com



smime.p7s
Description: S/MIME cryptographic signature

Re: catalina full disk access

[Ryan Schmidt]

On Jan 26, 2022, at 08:24, Arno S. Hautala wrote:

> On 25 Jan 2022, at 12:39, paul wrote:
> 
>> /usr/sbin/cron
>> /opt/local/bin/bash
>> /opt/local/bin/rsnapshot
>> /opt/local/bin/rsync
>> /opt/local/bin/gcp 
>> all have full disk access in system preferences.

I'm not sure if this is it, I've only had a few months of experience with OS 
versions that have this "full disk access" thing, but it seems like if you 
authorize a binary to do something, and then update the binary (for example in 
this case with "sudo port upgrade outdated"), then the authorization goes away 
even though the binary is still listed as authorized in System Preferences. Can 
you try removing the item's authorization in System Preferences and then 
re-adding it?

> The behavior has also seen some changes under different OS versions. What are 
> you using?

Subject line says Catalina.

Re: catalina full disk access

[Arno S. Hautala]

This isn’t specific to MacPorts, but is a more general issue with recent 
versions of macOS and “Full Disk Access”.

What I’ve found is that any binaries you add to Full Disk Access won’t actually 
be authorized. Authorized applications seem to need a bundle identifier. The 
behavior has also seen some changes under different OS versions. What are you 
using?

In theory, you should be able to create a wrapper application with Platypus 
[1]. But, I couldn’t get Platypus to work and had to create a Menu Bar 
application. It may be that the binary needs to be found within the app bundle?

[1]: https://sveinbjorn.org/platypus

See also [2], which includes a number of links at the end, including [3], which 
does sound to have some working solutions.

[2]: 
https://n8henrie.com/2018/11/how-to-give-full-disk-access-to-a-binary-in-macos-mojave/
[3]: https://github.com/restic/restic/issues/2051

-- 
arno  s  hautala/-|   a...@alum.wpi.edu

pgp b2c9d448




> On 25 Jan 2022, at 12:39, macpo...@parvis.nl wrote:
> 
> from cron i run a bash job that runs a bash job that runs rsnapshot from an 
> external usb disk to another external usb disk. 
> gcp -al (called from rsnapshot) fails with operation not permitted.
> it runs fine from ssh from iterm on another mac.
> 
> /usr/sbin/cron
> /opt/local/bin/bash
> /opt/local/bin/rsnapshot
> /opt/local/bin/rsync
> /opt/local/bin/gcp 
> all have full disk access in system preferences.
> 
> what can i do?
> 
> thanks,
> paul.

catalina full disk access

[macpo...@parvis.nl]

from cron i run a bash job that runs a bash job that runs rsnapshot from an 
external usb disk to another external usb disk. 
gcp -al (called from rsnapshot) fails with operation not permitted.
it runs fine from ssh from iterm on another mac.

/usr/sbin/cron
/opt/local/bin/bash
/opt/local/bin/rsnapshot
/opt/local/bin/rsync
/opt/local/bin/gcp 
all have full disk access in system preferences.

what can i do?

thanks,
paul.

Re: No user or group to remove on macOS Catalina

[Ryan Schmidt]

On Nov 27, 2021, at 02:22, Pieter van Oostrum wrote:

> chilli.names...@gmail.com writes:
> 
>> To uninstall macports entirely, I use the three commands below in a script 
>> (which I assume I got
>> from the manual, but it's been awhile, I do not recall), but they work just 
>> as well one at a time:
>> 
>> sudo port -vfp uninstall --follow-dependencies installed  
>> 
>> sudo port -vfp uninstall all
>> 
>> sudo rm -rf   /opt/local   /Library/Tcl/macports*
> 
> You may also have to add
> 
> sudo rm -rf /Applications/Macports

The link to the correct uninstallation instructions were already provided in 
the first message of this thread.

Re: No user or group to remove on macOS Catalina

[chilli.names...@gmail.com]

I don't consider /Applications/MacPorts part of the installation. And deleting 
binaries I built would be like... not only uprooting the tree, but destroying 
the fruit as well. That said, you have fair point.

> On Nov 27, 2021, at 03:22, Pieter van Oostrum  wrote:
> 
> "chilli.names...@gmail.com"  writes:
> 
>> To uninstall macports entirely, I use the three commands below in a script 
>> (which I assume I got
>> from the manual, but it's been awhile, I do not recall), but they work just 
>> as well one at a time:
>> 
>> sudo port -vfp uninstall --follow-dependencies installed  
>> 
>> sudo port -vfp uninstall all
>> 
>> sudo rm -rf   /opt/local   /Library/Tcl/macports*
> 
> You may also have to add
> 
> sudo rm -rf /Applications/Macports
> -- 
> Pieter van Oostrum 
> www: http://pieter.vanoostrum.org/
> PGP key: [8DAE142BE17999C4]

Re: No user or group to remove on macOS Catalina

[Pieter van Oostrum]

"chilli.names...@gmail.com"  writes:

> To uninstall macports entirely, I use the three commands below in a script 
> (which I assume I got
> from the manual, but it's been awhile, I do not recall), but they work just 
> as well one at a time:
>
> sudo port -vfp uninstall --follow-dependencies installed  
>
> sudo port -vfp uninstall all
>
> sudo rm -rf   /opt/local   /Library/Tcl/macports*

You may also have to add

sudo rm -rf /Applications/Macports
-- 
Pieter van Oostrum 
www: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]

Re: No user or group to remove on macOS Catalina

[André-John Mas]

I would say the big benefit of MacPorts over Brew is that it feels more secure, 
mainly because it doesn’t do everything as an unprivileged user. 

André-John

Sent from my phone. Envoyé depuis mon téléphone. 

> On 26 Nov 2021, at 19:50, Dave Horsfall  wrote:
> 
> On Fri, 26 Nov 2021, Ryan Schmidt wrote:
> 
>> You're right, it's best to pick one package manager and uninstall the 
>> other, to avoid them conflicting with one another. If you have any 
>> feedback about ways that MacPorts could improve, please let us know.
> 
> I'm not sure how I came across MacPorts, but I wouldn't switch away from 
> it for quids; it serves my purposes perfectly.  Keep up the great work!
> 
> -- Dave

Re: No user or group to remove on macOS Catalina

[Dave Horsfall]

On Fri, 26 Nov 2021, Ryan Schmidt wrote:

> You're right, it's best to pick one package manager and uninstall the 
> other, to avoid them conflicting with one another. If you have any 
> feedback about ways that MacPorts could improve, please let us know.

I'm not sure how I came across MacPorts, but I wouldn't switch away from 
it for quids; it serves my purposes perfectly.  Keep up the great work!

-- Dave

Re: No user or group to remove on macOS Catalina

[chilli.names...@gmail.com]

To uninstall macports entirely, I use the three commands below in a script 
(which I assume I got from the manual, but it's been awhile, I do not recall), 
but they work just as well one at a time:

sudo port -vfp uninstall --follow-dependencies installed  

sudo port -vfp uninstall all

sudo rm -rf   /opt/local   /Library/Tcl/macports*


> On Nov 26, 2021, at 08:16, Masoud Ghaderi  wrote:
> 
> 
> Hello,
> I am following the steps from 
> https://guide.macports.org/chunked/installing.macports.uninstalling.html to 
> remove mac ports from my machine (it is currently functioning but I want to 
> migrate to homebrew and I've heard they do not coexist).
> The second step states that I need to remove the user or group that has been 
> created by macports. However, looking for the user (as suggested in SO)
> /usr/bin/dscl . -search /Users name macports
> returns nothing. Also, running step 3 with -v flag did not return anything. 
> Executing 
> where port
> returned
> /opt/local/bin/port
> 
> Any help regarding the proper uninstallation of macports would be appreciated.
> 
> Regards,
> Masoud

Re: No user or group to remove on macOS Catalina

[Ryan Schmidt]

On Nov 26, 2021, at 07:16, Masoud Ghaderi wrote:

> Hello,
> I am following the steps from 
> https://guide.macports.org/chunked/installing.macports.uninstalling.html to 
> remove mac ports from my machine (it is currently functioning but I want to 
> migrate to homebrew and I've heard they do not coexist).
> The second step states that I need to remove the user or group that has been 
> created by macports. However, looking for the user (as suggested in SO)
> /usr/bin/dscl . -search /Users name macports
> returns nothing. Also, running step 3 with -v flag did not return anything. 
> Executing 
> where port
> returned
> /opt/local/bin/port
> 
> Any help regarding the proper uninstallation of macports would be appreciated.
> 
> Regards,
> Masoud

You're right, it's best to pick one package manager and uninstall the other, to 
avoid them conflicting with one another. If you have any feedback about ways 
that MacPorts could improve, please let us know.


On my Catalina system:


$ /usr/bin/dscl . -search /Users name macports
macportsdsAttrTypeNative:name = (
macports
)


If you don't get that result, then I guess you don't have the macports user, so 
you can skip the step of deleting it.

No user or group to remove on macOS Catalina

[Masoud Ghaderi]

Hello,
I am following the steps from
https://guide.macports.org/chunked/installing.macports.uninstalling.html to
remove mac ports from my machine (it is currently functioning but I want to
migrate to homebrew and I've heard they do not coexist).
The second step states that I need to remove the user or group that has
been created by macports. However, looking for the user (as suggested in SO)

/usr/bin/dscl . -search /Users name macports

returns nothing. Also, running step 3 with -v flag did not return anything.
Executing
where port
returned
/opt/local/bin/port

Any help regarding the proper uninstallation of macports would be
appreciated.

Regards,
Masoud

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Gerben Wierda via macports-users]

I contacted NLNet Labs, they updated their certs which made NSD fetch on Mojave 
work again for me.

Somewhere during my tests accidentally OpenSSL was activated on my machine (a 
destroot on nsd 4.3.8 maybe?), which killed all the installed ports that were 
dependent on an opensll 1.1.1 dylib (which had been made inaccessible), so 
suddenly a lot of programs couldn’t start anymore (Abort 6) because the dylib 
wasn’t there. That kind of forced me to do a quick update of everything.

So I updated NSD to 4.3.8 and created a pull request for it (as the existing 
MacPorts version 4.1.2 would not compile with OpenSSL3 which is now standard 
and I am an NSD maintainer)

That change has now been merged with MacPorts master (yes! yes! I did it 
correctly! I’m getting the hang of it!)

Everything NSD is back as it should be.

Gerben Wierda (LinkedIn )
R&A Enterprise Architecture  (main site)
Book: Chess and the Art of Enterprise Architecture 
Book: Mastering ArchiMate 

> On 8 Nov 2021, at 03:54, Dave Horsfall  wrote:
> 
> On Sun, 7 Nov 2021, Bill Cole wrote:
> 
>>> So I wonder how widespread this problem is?
>> 
>> The problem in this case is not the existence of the cert in the CA bundle, 
>> but the fact that this particular expired cert was used in an alternative 
>> validation path and the logic of verification for multi-path certs isn't 
>> correct. Normally, expired root CAs should stay in there because that allows 
>> positive non-verification of certs supposedly issued by an expired (and 
>> maybe compromised) root CA.
> 
> Gotcha; thanks.
> 
>>> And I'm not happy with those that are set way in the future; I heard 
>>> somewhere that 5 years is the recommended max.
>> 
>> CAs are special. The current limit on server certs is 397 days. I don't 
>> think there's a consensus on CA lifetimes because of the conflicting risks 
>> of too-short and too-long lives.
> 
> One day past a leap year :-)  I don't remember where I saw the 5-year 
> recommendation, unfortunately.
> 
> -- Dave

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Dave Horsfall]

On Sun, 7 Nov 2021, Bill Cole wrote:


So I wonder how widespread this problem is?


The problem in this case is not the existence of the cert in the CA 
bundle, but the fact that this particular expired cert was used in an 
alternative validation path and the logic of verification for multi-path 
certs isn't correct. Normally, expired root CAs should stay in there 
because that allows positive non-verification of certs supposedly issued 
by an expired (and maybe compromised) root CA.


Gotcha; thanks.

And I'm not happy with those that are set way in the future; I heard 
somewhere that 5 years is the recommended max.


CAs are special. The current limit on server certs is 397 days. I don't 
think there's a consensus on CA lifetimes because of the conflicting 
risks of too-short and too-long lives.


One day past a leap year :-)  I don't remember where I saw the 5-year 
recommendation, unfortunately.


-- Dave

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Bill Cole]

On 2021-11-07 at 16:29:30 UTC-0500 (Mon, 8 Nov 2021 08:29:30 +1100 
(EST))

Dave Horsfall 
is rumored to have said:


On Sun, 7 Nov 2021, Bill Cole wrote:

I have my own Mojave machines working without a problem after 
removing the bad certificate from /etc/ssl/cert.pem. The one that 
starts like this:


[...]

Intrigued, I checked my own:

mackie:~ dave$ grep "Not After" /etc/ssl/cert.pem


[... many dates snipped ...]

So I wonder how widespread this problem is?


The problem in this case is not the existence of the cert in the CA 
bundle, but the fact that this particular expired cert was used in an 
alternative validation path and the logic of verification for multi-path 
certs isn't correct. Normally, expired root CAs should stay in there 
because that allows positive non-verification of certs supposedly issued 
by an expired (and maybe compromised) root CA.


And I'm not happy with those that are set way in the future; I heard 
somewhere that 5 years is the recommended max.


CAs are special. The current limit on server certs is 397 days. I don't 
think there's a consensus on CA lifetimes because of the conflicting 
risks of too-short and too-long lives.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Dave Horsfall]

On Sun, 7 Nov 2021, Bill Cole wrote:

I have my own Mojave machines working without a problem after removing 
the bad certificate from /etc/ssl/cert.pem. The one that starts like 
this:


[...]

Intrigued, I checked my own:

mackie:~ dave$ grep "Not After" /etc/ssl/cert.pem


Not After : Aug 13 23:59:00 2018 GMT
Not After : Aug 22 16:41:51 2018 GMT
Not After: Aug 22 16:41:51 2018 GMT
Not After : Aug  1 23:59:59 2028 GMT
Not After : Jan 28 12:00:00 2028 GMT
Not After : Dec 15 08:00:00 2021 GMT
Not After : Mar 18 10:00:00 2029 GMT
Not After : Dec 31 23:59:59 2020 GMT
Not After : Dec 31 23:59:59 2020 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Jan 18 23:59:59 2038 GMT
Not After : Dec  1 23:59:59 2037 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Sep 17 19:46:36 2036 GMT
Not After : Jun 26 00:19:54 2019 GMT
Not After : May 25 16:39:40 2019 GMT
Not Before: May 25 16:09:40 1999 GMT, Not After: May 25 
16:09:40 2019 GMT
Not After : Nov 10 00:00:00 2031 GMT
Not After : Nov 10 00:00:00 2031 GMT
Not After : Nov 10 00:00:00 2031 GMT
Not After : Jun 21 04:00:00 2020 GMT
Not After : Jun 21 04:00:00 2020 GMT
Not After : May 21 04:00:00 2022 GMT
Not After : Mar  4 05:00:00 2019 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Dec  1 23:59:59 2037 GMT
Not After : Mar  4 05:00:00 2029 GMT
Not After : Mar  4 05:00:00 2029 GMT
Not After : Jun 29 17:06:20 2034 GMT
Not After : Dec 31 23:59:59 2037 GMT
Not After : Jun 29 17:39:16 2034 GMT
Not After : Dec 31 23:59:59 2037 GMT
Not After : Dec 31 23:59:59 2037 GMT
Not After : Dec 31 23:59:01 2039 GMT
Not After : Jul 16 23:59:59 2036 GMT
Not After : Jan 18 23:59:59 2038 GMT
Not After : Dec  1 23:59:59 2037 GMT
Not After : May 30 10:48:38 2020 GMT
Not After : Dec 31 23:59:59 2028 GMT
Not After : Jul  9 18:19:22 2019 GMT
Not After : May 12 23:59:00 2025 GMT
Not After : Jul  9 23:59:00 2019 GMT
Not After : Oct  1 23:59:59 2033 GMT
Not After : Oct  1 23:59:59 2033 GMT
Not After : Oct 25 08:30:35 2036 GMT
Not After : Oct 25 08:36:00 2036 GMT
Not After : Oct 25 08:32:46 2036 GMT
Not After : Sep 30 14:01:15 2021 GMT
Not After : Dec  6 15:08:21 2028 GMT

So I wonder how widespread this problem is?  And I'm not happy with those 
that are set way in the future; I heard somewhere that 5 years is the 
recommended max.


-- Dave

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Bill Cole]

On 2021-11-07 at 06:40:01 UTC-0500 (Sun, 7 Nov 2021 12:40:01 +0100)
Gerben Wierda via macports-users 
is rumored to have said:

The reason is libcurl in Mojave which is less permissive than High 
Sierra.


I'm unconvinced of that.

I have my own Mojave machines working without a problem after removing 
the bad certificate from /etc/ssl/cert.pem. The one that starts like 
this:


-### Digital Signature Trust Co.
-
-=== /O=Digital Signature Trust Co./CN=DST Root CA X3
-Certificate:
-Data:
-Version: 3 (0x2)
-Serial Number:
-44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
-Signature Algorithm: sha1WithRSAEncryption
-Validity
-Not Before: Sep 30 21:12:19 2000 GMT
-Not After : Sep 30 14:01:15 2021 GMT






On 7 Nov 2021, at 03:08, Kastus Shchuka  wrote:

Something does not add up here.

High Sierra is older than Mojave, right? I can fetch sources of nsd 
on High Sierra without any problems:


$ sudo port -d fetch nsd
DEBUG: Copying 
/Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd

DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies

DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: Attempting ln -sf 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work

DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: Starting logging for nsd @4.2.1_2
DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
DEBUG: MacPorts 2.7.1
DEBUG: Xcode 9.4.1
DEBUG: SDK 10.13
DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
DEBUG: Executing org.macports.main (nsd)
DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
--->  Fetching distfiles for nsd
DEBUG: elevating privileges for fetch: euid changed to 0, egid 
changed to 0.

DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: Executing org.macports.fetch (nsd)
--->  nsd-4.2.1.tar.gz does not exist in 
/opt/local/var/macports/distfiles/nsd
--->  Attempting to fetch nsd-4.2.1.tar.gz from 
http://distfiles.macports.org/nsd
 % Total% Received % Xferd  Average Speed   TimeTime Time 
 Current
Dload  Upload   Total   SpentLeft 
 Speed
100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- 
--:--:-- 3563k

$ ls -l /opt/local/var/macports/distfiles/nsd
total 2240
-rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz

I have MacPorts installed from a package, I did not build it, so it 
is pretty much standard. Neither I did anything to the system 
certificate chain.


On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  
wrote:





On Nov 6, 2021, at 05:39, Gerben Wierda wrote:

I was looking at updating nsd (for which I am maintaining and it is 
high time)


But fetching failed on macOS Mojave (where I have my MacPorts 
setup).


:debug:fetch Executing org.macports.fetch (nsd)
:info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
/opt/local/var/macports/distfiles/nsd
:notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
https://www.nlnetlabs.nl/downloads/nsd/
:debug:fetch Fetching distfile failed: SSL certificate problem: 
certificate has expired


Now, my main MacPorts dev/use machine is macOS Mojave so I suspect 
that is the Mojave-doesn’t-get-root-cert-updates problem. So, I 
tried to do a port fetch on Catalina, and there it works and the 
distribution is downloaded.


It is strange, though, because Safari on both Catalina (other 
machine) and Mojave say the cert is fine. Still, it is most likely 
that this is a problem that comes from still using Mojave.


Updating that machine will not happen until late December, so if I 
am to maintain anything MacPorts, I need a fix to get this working 
again.


I have tried using curl on the Mojave machine, and that one works.

So, Safari works, curl works, but port does not work.

I tried copying /etc/ssl/cert.pem over to the Mojave machine, but 
that doesn’t work either.


This is the "Let's Encrypt's old root certificate expire

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[André-John Mas]

gt;> 
>>>>> I was looking at updating nsd (for which I am maintaining and it is high 
>>>>> time)
>>>>> 
>>>>> But fetching failed on macOS Mojave (where I have my MacPorts setup).
>>>>> 
>>>>> :debug:fetch Executing org.macports.fetch (nsd)
>>>>> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
>>>>> /opt/local/var/macports/distfiles/nsd
>>>>> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
>>>>> https://www.nlnetlabs.nl/downloads/nsd/
>>>>> :debug:fetch Fetching distfile failed: SSL certificate problem: 
>>>>> certificate has expired
>>>>> 
>>>>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that 
>>>>> is the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a 
>>>>> port fetch on Catalina, and there it works and the distribution is 
>>>>> downloaded.
>>>>> 
>>>>> It is strange, though, because Safari on both Catalina (other machine) 
>>>>> and Mojave say the cert is fine. Still, it is most likely that this is a 
>>>>> problem that comes from still using Mojave.
>>>>> 
>>>>> Updating that machine will not happen until late December, so if I am to 
>>>>> maintain anything MacPorts, I need a fix to get this working again.
>>>>> 
>>>>> I have tried using curl on the Mojave machine, and that one works.
>>>>> 
>>>>> So, Safari works, curl works, but port does not work.
>>>>> 
>>>>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
>>>>> doesn’t work either.
>>>> 
>>>> This is the "Let's Encrypt's old root certificate expired" problem 
>>>> described here:
>>>> 
>>>> https://trac.macports.org/wiki/ProblemHotlist#letsencrypt
>>>> 
>>>> When you said "curl works but port does not work" that's not quite right. 
>>>> /opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl 
>>>> and /usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) 
>>>> do not work for Let's Encrypt-protected sites anymore.
>>>> 
>>>> I, on High Sierra, have the same issue, and I have no solution for you. 
>>>> This issue affects High Sierra and Mojave. I recommend upgrading to 
>>>> Catalina or later; I plan to eventually.
>>>> 
>>>> Well, you could rebuild MacPorts from source, instructing it to use a 
>>>> newer copy of libcurl with a newer copy of openssl or libressl that has a 
>>>> newer certificate bundle. For example, install a bootstrap copy of 
>>>> MacPorts in a separate prefix, install curl in that prefix, then rebuild 
>>>> your primary MacPorts from source, telling it to use the libcurl in the 
>>>> separate prefix. Any future upgrades to MacPorts base probably also have 
>>>> to be done from source; using "sudo port selfupdate" will not preserve 
>>>> your configure arguments and you'll be back to using the System's broken 
>>>> libcurl again.
>>> 
> 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Ryan Schmidt]

On Nov 7, 2021, at 00:03, Kastus Shchuka wrote:
> 
> On the other hand, it's plain dumb why it works for me. As you can see below, 
> org.macports.fetch does not use HTTPS, it downloads over HTTP. Certificates 
> are just irrelevant for that.
> 
> I am not sure what part of macports.conf controls protocol for fetch,

Right. We already modified MacPorts so that it knows on which OS versions https 
won't work -- with regard to our mirror servers only.

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

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Gerben Wierda via macports-users]

The reason is libcurl in Mojave which is less permissive than High Sierra.

Sent from my iPhone

> On 7 Nov 2021, at 03:08, Kastus Shchuka  wrote:
> 
> Something does not add up here.
> 
> High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
> Sierra without any problems:
> 
> $ sudo port -d fetch nsd
> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
> /opt/local/var/macports/home/Library/Preferences
> DEBUG: Changing to port directory: 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
> DEBUG: adding the default universal variant
> DEBUG: Reading variant descriptions from 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
> DEBUG: Finished running callback 
> portconfigure::add_automatic_compiler_dependencies
> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Finished running callback 
> portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Running callback portstartupitem::add_notes
> DEBUG: Finished running callback portstartupitem::add_notes
> DEBUG: Attempting ln -sf 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
>  
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: Starting logging for nsd @4.2.1_2
> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
> DEBUG: MacPorts 2.7.1
> DEBUG: Xcode 9.4.1
> DEBUG: SDK 10.13
> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
> DEBUG: Executing org.macports.main (nsd)
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
> --->  Fetching distfiles for nsd
> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: Executing org.macports.fetch (nsd)
> --->  nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd
> --->  Attempting to fetch nsd-4.2.1.tar.gz from 
> http://distfiles.macports.org/nsd
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
> 100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 3563k
> $ ls -l /opt/local/var/macports/distfiles/nsd
> total 2240
> -rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz
> 
> I have MacPorts installed from a package, I did not build it, so it is pretty 
> much standard. Neither I did anything to the system certificate chain.
> 
>> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
>> 
>> 
>> 
>>> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
>>> 
>>> I was looking at updating nsd (for which I am maintaining and it is high 
>>> time)
>>> 
>>> But fetching failed on macOS Mojave (where I have my MacPorts setup).
>>> 
>>> :debug:fetch Executing org.macports.fetch (nsd)
>>> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
>>> /opt/local/var/macports/distfiles/nsd
>>> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
>>> https://www.nlnetlabs.nl/downloads/nsd/
>>> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate 
>>> has expired
>>> 
>>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
>>> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
>>> fetch on Catalina, and there it works and the distribution is downloaded.
>>> 
>>> It is strange, though, because Safari on both Catalina (other machine) and 
>>> Mojave say the cert is fine. Still, it is most likely that this is a 
>>> problem that comes from still using Mojave.
>>> 
>>> Updating that machine will not happen until late December, so if I am to 
>>> maintain anything MacPorts, I need a fix to get this working again.
>>> 
>>> I have tried using curl on the Mojave machine, and that one works.
>>> 
>>> So, Safari works, curl works, but port does not work.
>>> 
>>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
>>> doesn’t work either.
>> 
>> This is the "Let's Encrypt

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Masha Vecherkovskaya]

ports/release/tarballs/ports/net/nsd/work
>>   
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.  
>> DEBUG: Starting logging for nsd @4.2.1_2  
>> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386  
>> DEBUG: MacPorts 2.7.1  
>> DEBUG: Xcode 9.4.1  
>> DEBUG: SDK 10.13  
>> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13  
>> DEBUG: Executing org.macports.main (nsd)  
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.  
>> DEBUG: fetch phase started at Sat Nov 6 19:00:42 PDT 2021  
>> ---> Fetching distfiles for nsd  
>> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0. 
>>  
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.  
>> DEBUG: Executing org.macports.fetch (nsd)  
>> ---> nsd-4.2.1.tar.gz does not exist in 
>> /opt/local/var/macports/distfiles/nsd  
>> ---> Attempting to fetch nsd-4.2.1.tar.gz from 
>> http://distfiles.macports.org/nsd  
>> % Total % Received % Xferd Average Speed Time Time Time Current  
>> Dload Upload Total Spent Left Speed  
>> 100 1118k 100 1118k 0 0 3557k 0 --:--:-- --:--:-- --:--:-- 3563k  
>> $ ls -l /opt/local/var/macports/distfiles/nsd  
>> total 2240  
>> -rw-r--r-- 1 macports wheel 1145713 Nov 6 19:00 nsd-4.2.1.tar.gz  
>>  
>> I have MacPorts installed from a package, I did not build it, so it is 
>> pretty much standard. Neither I did anything to the system certificate 
>> chain.  
>>  
>>> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:  
>>>  
>>>  
>>>  
>>>> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:  
>>>>  
>>>> I was looking at updating nsd (for which I am maintaining and it is high 
>>>> time)  
>>>>  
>>>> But fetching failed on macOS Mojave (where I have my MacPorts setup).  
>>>>  
>>>> :debug:fetch Executing org.macports.fetch (nsd)  
>>>> :info:fetch ---> nsd-4.3.8.tar.gz does not exist in 
>>>> /opt/local/var/macports/distfiles/nsd  
>>>> :notice:fetch ---> Attempting to fetch nsd-4.3.8.tar.gz from 
>>>> https://www.nlnetlabs.nl/downloads/nsd/  
>>>> :debug:fetch Fetching distfile failed: SSL certificate problem: 
>>>> certificate has expired  
>>>>  
>>>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
>>>> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
>>>> fetch on Catalina, and there it works and the distribution is downloaded.  
>>>>  
>>>> It is strange, though, because Safari on both Catalina (other machine) and 
>>>> Mojave say the cert is fine. Still, it is most likely that this is a 
>>>> problem that comes from still using Mojave.  
>>>>  
>>>> Updating that machine will not happen until late December, so if I am to 
>>>> maintain anything MacPorts, I need a fix to get this working again.  
>>>>  
>>>> I have tried using curl on the Mojave machine, and that one works.  
>>>>  
>>>> So, Safari works, curl works, but port does not work.  
>>>>  
>>>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
>>>> doesn’t work either.  
>>>  
>>> This is the "Let's Encrypt's old root certificate expired" problem 
>>> described here:  
>>>  
>>> https://trac.macports.org/wiki/ProblemHotlist#letsencrypt  
>>>  
>>> When you said "curl works but port does not work" that's not quite right. 
>>> /opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl 
>>> and /usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) 
>>> do not work for Let's Encrypt-protected sites anymore.  
>>>  
>>> I, on High Sierra, have the same issue, and I have no solution for you. 
>>> This issue affects High Sierra and Mojave. I recommend upgrading to 
>>> Catalina or later; I plan to eventually.  
>>>  
>>> Well, you could rebuild MacPorts from source, instructing it to use a newer 
>>> copy of libcurl with a newer copy of openssl or libressl that has a newer 
>>> certificate bundle. For example, install a bootstrap copy of MacPorts in a 
>>> separate prefix, install curl in that prefix, then rebuild your primary 
>>> MacPorts from source, telling it to use the libcurl in the separate prefix. 
>>> Any future upgrades to MacPorts base probably also have to be done from 
>>> source; using "sudo port selfupdate" will not preserve your configure 
>>> arguments and you'll be back to using the System's broken libcurl again.  
>>  

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Kastus Shchuka]

> On Nov 6, 2021, at 7:53 PM, André-John Mas  wrote:
> 
> Does it make a difference if you test via sudo or your own user login?
> 

Well, it won't work as regular user. Regular user does not have write 
permissions to /opt/local tree.

On the other hand, it's plain dumb why it works for me. As you can see below, 
org.macports.fetch does not use HTTPS, it downloads over HTTP. Certificates are 
just irrelevant for that.

I am not sure what part of macports.conf controls protocol for fetch, I have 
not modified that file since 2017. (I guess I should have done it). I looked at 
the diff between my macports.conf and macports.conf.default from May 2021, and 
I don't see anything with regards to http/https. I must be missing something 
there.

Thanks,

Kastus

> André-John
> 
> Sent from my phone. Envoyé depuis mon téléphone. 
> 
>> On 06 Nov 2021, at 22:08, Kastus Shchuka  wrote:
>> 
>> Something does not add up here.
>> 
>> High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
>> Sierra without any problems:
>> 
>> $ sudo port -d fetch nsd
>> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
>> /opt/local/var/macports/home/Library/Preferences
>> DEBUG: Changing to port directory: 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
>> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
>> DEBUG: adding the default universal variant
>> DEBUG: Reading variant descriptions from 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
>> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
>> DEBUG: Finished running callback 
>> portconfigure::add_automatic_compiler_dependencies
>> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
>> DEBUG: Finished running callback 
>> portbuild::add_automatic_buildsystem_dependencies
>> DEBUG: Running callback portstartupitem::add_notes
>> DEBUG: Finished running callback portstartupitem::add_notes
>> DEBUG: Attempting ln -sf 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
>>  
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>> DEBUG: Starting logging for nsd @4.2.1_2
>> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
>> DEBUG: MacPorts 2.7.1
>> DEBUG: Xcode 9.4.1
>> DEBUG: SDK 10.13
>> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
>> DEBUG: Executing org.macports.main (nsd)
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>> DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
>> --->  Fetching distfiles for nsd
>> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
>> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
>> DEBUG: Executing org.macports.fetch (nsd)
>> --->  nsd-4.2.1.tar.gz does not exist in 
>> /opt/local/var/macports/distfiles/nsd
>> --->  Attempting to fetch nsd-4.2.1.tar.gz from 
>> http://distfiles.macports.org/nsd
>> % Total% Received % Xferd  Average Speed   TimeTime Time  Current
>>Dload  Upload   Total   SpentLeft  Speed
>> 100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 
>> 3563k
>> $ ls -l /opt/local/var/macports/distfiles/nsd
>> total 2240
>> -rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz
>> 
>> I have MacPorts installed from a package, I did not build it, so it is 
>> pretty much standard. Neither I did anything to the system certificate chain.
>> 
>>> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
>>> 
>>> 
>>> 
>>>> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
>>>> 
>>>> I was looking at updating nsd (for which I am maintaining and it is high 
>>>> time)
>>>> 
>>>> But fetching failed on macOS Mojave (where I have my MacPorts setup).
>>>> 
>>>> :debug:fetch Executing org.macports.fetch (nsd)
>>>> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
>>>> /opt/local/var/macports/distfiles/nsd
>>>> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
>>>> https://www.nlnetlabs.nl/downloads/nsd/
>>>> :debug:fetch Fetching distfile failed: SSL certificate problem: 
>>>> c

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[André-John Mas]

Does it make a difference if you test via sudo or your own user login?

André-John

Sent from my phone. Envoyé depuis mon téléphone. 

> On 06 Nov 2021, at 22:08, Kastus Shchuka  wrote:
> 
> Something does not add up here.
> 
> High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
> Sierra without any problems:
> 
> $ sudo port -d fetch nsd
> DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
> /opt/local/var/macports/home/Library/Preferences
> DEBUG: Changing to port directory: 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
> DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
> DEBUG: adding the default universal variant
> DEBUG: Reading variant descriptions from 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
> DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
> DEBUG: Finished running callback 
> portconfigure::add_automatic_compiler_dependencies
> DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Finished running callback 
> portbuild::add_automatic_buildsystem_dependencies
> DEBUG: Running callback portstartupitem::add_notes
> DEBUG: Finished running callback portstartupitem::add_notes
> DEBUG: Attempting ln -sf 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
>  
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: Starting logging for nsd @4.2.1_2
> DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
> DEBUG: MacPorts 2.7.1
> DEBUG: Xcode 9.4.1
> DEBUG: SDK 10.13
> DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
> DEBUG: Executing org.macports.main (nsd)
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
> --->  Fetching distfiles for nsd
> DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
> DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
> DEBUG: Executing org.macports.fetch (nsd)
> --->  nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd
> --->  Attempting to fetch nsd-4.2.1.tar.gz from 
> http://distfiles.macports.org/nsd
>  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
> Dload  Upload   Total   SpentLeft  Speed
> 100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 3563k
> $ ls -l /opt/local/var/macports/distfiles/nsd
> total 2240
> -rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz
> 
> I have MacPorts installed from a package, I did not build it, so it is pretty 
> much standard. Neither I did anything to the system certificate chain.
> 
>> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
>> 
>> 
>> 
>>> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
>>> 
>>> I was looking at updating nsd (for which I am maintaining and it is high 
>>> time)
>>> 
>>> But fetching failed on macOS Mojave (where I have my MacPorts setup).
>>> 
>>> :debug:fetch Executing org.macports.fetch (nsd)
>>> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
>>> /opt/local/var/macports/distfiles/nsd
>>> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
>>> https://www.nlnetlabs.nl/downloads/nsd/
>>> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate 
>>> has expired
>>> 
>>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
>>> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
>>> fetch on Catalina, and there it works and the distribution is downloaded.
>>> 
>>> It is strange, though, because Safari on both Catalina (other machine) and 
>>> Mojave say the cert is fine. Still, it is most likely that this is a 
>>> problem that comes from still using Mojave.
>>> 
>>> Updating that machine will not happen until late December, so if I am to 
>>> maintain anything MacPorts, I need a fix to get this working again.
>>> 
>>> I have tried using curl on the Mojave machine, and that one works.
>>> 
>>> So, Safari works, curl works, but port does not work.
>>> 
>>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
>>> doesn’t work either.
>> 
>> 

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Kastus Shchuka]

Something does not add up here.

High Sierra is older than Mojave, right? I can fetch sources of nsd on High 
Sierra without any problems:

$ sudo port -d fetch nsd
DEBUG: Copying /Users/pike/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd
DEBUG: OS darwin/17.7.0 (macOS 10.13.6) arch i386
DEBUG: adding the default universal variant
DEBUG: Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf
DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies
DEBUG: Finished running callback 
portconfigure::add_automatic_compiler_dependencies
DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies
DEBUG: Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
DEBUG: Running callback portstartupitem::add_notes
DEBUG: Finished running callback portstartupitem::add_notes
DEBUG: Attempting ln -sf 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_net_nsd/nsd/work
 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/net/nsd/work
DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: Starting logging for nsd @4.2.1_2
DEBUG: macOS 10.13.6 (darwin/17.7.0) arch i386
DEBUG: MacPorts 2.7.1
DEBUG: Xcode 9.4.1
DEBUG: SDK 10.13
DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.13
DEBUG: Executing org.macports.main (nsd)
DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: fetch phase started at Sat Nov  6 19:00:42 PDT 2021
--->  Fetching distfiles for nsd
DEBUG: elevating privileges for fetch: euid changed to 0, egid changed to 0.
DEBUG: dropping privileges: euid changed to 504, egid changed to 20.
DEBUG: Executing org.macports.fetch (nsd)
--->  nsd-4.2.1.tar.gz does not exist in /opt/local/var/macports/distfiles/nsd
--->  Attempting to fetch nsd-4.2.1.tar.gz from 
http://distfiles.macports.org/nsd
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 1118k  100 1118k0 0  3557k  0 --:--:-- --:--:-- --:--:-- 3563k
$ ls -l /opt/local/var/macports/distfiles/nsd
total 2240
-rw-r--r--  1 macports  wheel  1145713 Nov  6 19:00 nsd-4.2.1.tar.gz

I have MacPorts installed from a package, I did not build it, so it is pretty 
much standard. Neither I did anything to the system certificate chain.

> On Nov 6, 2021, at 5:43 AM, Ryan Schmidt  wrote:
> 
> 
> 
> On Nov 6, 2021, at 05:39, Gerben Wierda wrote:
> 
>> I was looking at updating nsd (for which I am maintaining and it is high 
>> time)
>> 
>> But fetching failed on macOS Mojave (where I have my MacPorts setup).
>> 
>> :debug:fetch Executing org.macports.fetch (nsd)
>> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
>> /opt/local/var/macports/distfiles/nsd
>> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
>> https://www.nlnetlabs.nl/downloads/nsd/
>> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate 
>> has expired
>> 
>> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
>> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
>> fetch on Catalina, and there it works and the distribution is downloaded.
>> 
>> It is strange, though, because Safari on both Catalina (other machine) and 
>> Mojave say the cert is fine. Still, it is most likely that this is a problem 
>> that comes from still using Mojave.
>> 
>> Updating that machine will not happen until late December, so if I am to 
>> maintain anything MacPorts, I need a fix to get this working again.
>> 
>> I have tried using curl on the Mojave machine, and that one works.
>> 
>> So, Safari works, curl works, but port does not work.
>> 
>> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
>> doesn’t work either.
> 
> This is the "Let's Encrypt's old root certificate expired" problem described 
> here:
> 
> https://trac.macports.org/wiki/ProblemHotlist#letsencrypt
> 
> When you said "curl works but port does not work" that's not quite right. 
> /opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl and 
> /usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) do not 
> work for Let's Encrypt-protected sites anymore.
> 
> I, on High Sierra, have the same issue, and I have no solution for you. This 
> issue affects High

Re: port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Ryan Schmidt]

On Nov 6, 2021, at 05:39, Gerben Wierda wrote:

> I was looking at updating nsd (for which I am maintaining and it is high time)
> 
> But fetching failed on macOS Mojave (where I have my MacPorts setup).
> 
> :debug:fetch Executing org.macports.fetch (nsd)
> :info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
> /opt/local/var/macports/distfiles/nsd
> :notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
> https://www.nlnetlabs.nl/downloads/nsd/
> :debug:fetch Fetching distfile failed: SSL certificate problem: certificate 
> has expired
> 
> Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is 
> the Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port 
> fetch on Catalina, and there it works and the distribution is downloaded.
> 
> It is strange, though, because Safari on both Catalina (other machine) and 
> Mojave say the cert is fine. Still, it is most likely that this is a problem 
> that comes from still using Mojave.
> 
> Updating that machine will not happen until late December, so if I am to 
> maintain anything MacPorts, I need a fix to get this working again.
> 
> I have tried using curl on the Mojave machine, and that one works.
> 
> So, Safari works, curl works, but port does not work.
> 
> I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that 
> doesn’t work either.

This is the "Let's Encrypt's old root certificate expired" problem described 
here:

https://trac.macports.org/wiki/ProblemHotlist#letsencrypt

When you said "curl works but port does not work" that's not quite right. 
/opt/local/bin/curl and /opt/local/lib/libcurl.dylib work. /usr/bin/curl and 
/usr/lib/libcurl.dylib (the latter of which MacPorts uses by default) do not 
work for Let's Encrypt-protected sites anymore.

I, on High Sierra, have the same issue, and I have no solution for you. This 
issue affects High Sierra and Mojave. I recommend upgrading to Catalina or 
later; I plan to eventually.

Well, you could rebuild MacPorts from source, instructing it to use a newer 
copy of libcurl with a newer copy of openssl or libressl that has a newer 
certificate bundle. For example, install a bootstrap copy of MacPorts in a 
separate prefix, install curl in that prefix, then rebuild your primary 
MacPorts from source, telling it to use the libcurl in the separate prefix. Any 
future upgrades to MacPorts base probably also have to be done from source; 
using "sudo port selfupdate" will not preserve your configure arguments and 
you'll be back to using the System's broken libcurl again.

port cannot fetch because of expired cert, but cert is OK according to Safari, curl (question related to Mojave / Catalina)

[Gerben Wierda via macports-users]

I was looking at updating nsd (for which I am maintaining and it is high time)

But fetching failed on macOS Mojave (where I have my MacPorts setup).

:debug:fetch Executing org.macports.fetch (nsd)
:info:fetch --->  nsd-4.3.8.tar.gz does not exist in 
/opt/local/var/macports/distfiles/nsd
:notice:fetch --->  Attempting to fetch nsd-4.3.8.tar.gz from 
https://www.nlnetlabs.nl/downloads/nsd/ 
<https://www.nlnetlabs.nl/downloads/nsd/>
:debug:fetch Fetching distfile failed: SSL certificate problem: certificate has 
expired

Now, my main MacPorts dev/use machine is macOS Mojave so I suspect that is the 
Mojave-doesn’t-get-root-cert-updates problem. So, I tried to do a port fetch on 
Catalina, and there it works and the distribution is downloaded.

It is strange, though, because Safari on both Catalina (other machine) and 
Mojave say the cert is fine. Still, it is most likely that this is a problem 
that comes from still using Mojave.

Updating that machine will not happen until late December, so if I am to 
maintain anything MacPorts, I need a fix to get this working again.

I have tried using curl on the Mojave machine, and that one works.

So, Safari works, curl works, but port does not work.

I tried copying /etc/ssl/cert.pem over to the Mojave machine, but that doesn’t 
work either.

Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
R&A Enterprise Architecture <https://ea.rna.nl/> (main site)
Book: Chess and the Art of Enterprise Architecture <https://ea.rna.nl/the-book/>
Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>

Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes

[Tabitha McNerney]

Thank you Bjarne, this is great to know especially for those of us lagging
somewhat and getting ourselves more acquainted with the new volume formats
of Catalina and Big Sur, with Monterrey in the works. I would not be
surprised if Apple included the opt directory in /System/Volumes/Data
thanks in large part to MacPorts having a very long history of using /opt
and if I recall correctly Apple has long been supportive of MacPorts. What
a nice thing to learn today, making for a lovely day, in a world full of
noise and chaos. Have a great day and stay well.

-TM


On Fri, Jun 25, 2021 at 10:35 PM Bjarne D Mathiesen <
macint...@mathiesen.info> wrote:

>
>
> Tabitha McNerney wrote:
> > Hi all,
> >
> > I haven't installed a fresh MacPorts system in quite some time but will
> > soon be doing so on a few Macs one running Catalina and the other Big
> > Sur. Starting with Catalina, the root volume / is read-only so how do
> > the MacPorts package installers set things up such that /opt/local can
> > remain the default path to MacPorts for both read and write
> > functionality on Catalina and Big Sur?
>
> /opt is one of the directories Apple defines at the / level as part of
> the Data Volume
>
> > Do the MacPorts package
> > installers make use of Apple's new bi-directional firmlinks capability
> > defined in /etc/synthetic.conf as also described on this page?
> >
> >
> https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/
>
> No. That's not necessary as /opt transparently exists and is writable.
>
> >
> > Thank you.
> >
> > -TM
>
> In depth explanations are here :
>
> https://arstechnica.com/gadgets/2019/10/macos-10-15-catalina-the-ars-technica-review/11/#h1
>
> https://arstechnica.com/gadgets/2020/11/macos-11-0-big-sur-the-ars-technica-review/11/#h1
>
> So, If you go to /System/Volumes/Data in Terminal & do 'ls -l' you'll
> see the opt directory.
>
> --
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> ---
> denne besked er skrevet i et totalt M$-frit miljø
> MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina
> 2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM
> ATI Radeon RX 590 8 GB
>

Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes

[Bjarne D Mathiesen]

Tabitha McNerney wrote:
> Hi all,
> 
> I haven't installed a fresh MacPorts system in quite some time but will
> soon be doing so on a few Macs one running Catalina and the other Big
> Sur. Starting with Catalina, the root volume / is read-only so how do
> the MacPorts package installers set things up such that /opt/local can
> remain the default path to MacPorts for both read and write
> functionality on Catalina and Big Sur? 

/opt is one of the directories Apple defines at the / level as part of
the Data Volume

> Do the MacPorts package
> installers make use of Apple's new bi-directional firmlinks capability
> defined in /etc/synthetic.conf as also described on this page?
> 
> https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/

No. That's not necessary as /opt transparently exists and is writable.

> 
> Thank you.
> 
> -TM

In depth explanations are here :
https://arstechnica.com/gadgets/2019/10/macos-10-15-catalina-the-ars-technica-review/11/#h1
https://arstechnica.com/gadgets/2020/11/macos-11-0-big-sur-the-ars-technica-review/11/#h1

So, If you go to /System/Volumes/Data in Terminal & do 'ls -l' you'll
see the opt directory.

-- 
Bjarne D Mathiesen
Korsør ; Danmark ; Europa
---
denne besked er skrevet i et totalt M$-frit miljø
MacPro 2010 ; OpenCore + macOS 10.15.7 Catalina
2 x 3,46 GHz 6-Core Intel Xeon ; 256 GB 1333 MHz DDR3 ECC RDIMM
ATI Radeon RX 590 8 GB

Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes

[Tabitha McNerney]

Maybe the pkg installer software looks to see if an installation is trying
to mkdir in root and it automatically creates /etc/synthetic.conf with an
entry. That would be quintessential Apple to do something like that. Thank
you Apple, it just works.


On Fri, Jun 25, 2021 at 5:20 PM Ryan Schmidt 
wrote:

> On Jun 25, 2021, at 21:03, Tabitha McNerney wrote:
>
> > On a fresh Catalina or Big Sure system, if you cd to root / then sudo
> then try mkdir /opt or something else such as mkdir /hello the system won't
> allow it, I get this:
> >
> > mkdir: /hello: Read-only file system
> >
> > note: the MacBook I just tried this on also has FileVault enabled and
> its got one of those Apple T2 chips with a touch bar
> >
> > How does the MacPorts Catalina or Big Sur pkg installer work around this
> restriction?
>
> I don't know that we're doing anything. It just works.
>
> There is some mechanism, that I don't understand, by which the system
> volume and the data volume are combined into a single presentation.
> Presumably the Installer app knows that you cannot install to the system
> volume, so it installs MacPorts to the data volume.
>
>

Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes

[Ryan Schmidt]

On Jun 25, 2021, at 21:03, Tabitha McNerney wrote:

> On a fresh Catalina or Big Sure system, if you cd to root / then sudo then 
> try mkdir /opt or something else such as mkdir /hello the system won't allow 
> it, I get this:
> 
> mkdir: /hello: Read-only file system
> 
> note: the MacBook I just tried this on also has FileVault enabled and its got 
> one of those Apple T2 chips with a touch bar
> 
> How does the MacPorts Catalina or Big Sur pkg installer work around this 
> restriction?

I don't know that we're doing anything. It just works.

There is some mechanism, that I don't understand, by which the system volume 
and the data volume are combined into a single presentation. Presumably the 
Installer app knows that you cannot install to the system volume, so it 
installs MacPorts to the data volume.

Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes

[Tabitha McNerney]

On a fresh Catalina or Big Sure system, if you cd to root / then sudo then
try mkdir /opt or something else such as mkdir /hello the system won't
allow it, I get this:

mkdir: /hello: Read-only file system

note: the MacBook I just tried this on also has FileVault enabled and its
got one of those Apple T2 chips with a touch bar

How does the MacPorts Catalina or Big Sur pkg installer work around this
restriction?


On Fri, Jun 25, 2021 at 3:26 PM Ryan Schmidt 
wrote:

>
>
> On Jun 25, 2021, at 18:07, Tabitha McNerney wrote:
>
> > Hi all,
> >
> > I haven't installed a fresh MacPorts system in quite some time but will
> soon be doing so on a few Macs one running Catalina and the other Big Sur.
> Starting with Catalina, the root volume / is read-only so how do the
> MacPorts package installers set things up such that /opt/local can remain
> the default path to MacPorts for both read and write functionality on
> Catalina and Big Sur? Do the MacPorts package installers make use of
> Apple's new bi-directional firmlinks capability defined in
> /etc/synthetic.conf as also described on this page?
> >
> >
> https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/
> >
> > Thank you.
>
> I'm not aware of MacPorts doing anything special for this. It just works?
>
>
>

Re: MacPorts and /opt/local on Catalina and Big Sur read only volumes

[Ryan Schmidt]

On Jun 25, 2021, at 18:07, Tabitha McNerney wrote:

> Hi all,
> 
> I haven't installed a fresh MacPorts system in quite some time but will soon 
> be doing so on a few Macs one running Catalina and the other Big Sur. 
> Starting with Catalina, the root volume / is read-only so how do the MacPorts 
> package installers set things up such that /opt/local can remain the default 
> path to MacPorts for both read and write functionality on Catalina and Big 
> Sur? Do the MacPorts package installers make use of Apple's new 
> bi-directional firmlinks capability defined in /etc/synthetic.conf as also 
> described on this page? 
> 
> https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/
> 
> Thank you.

I'm not aware of MacPorts doing anything special for this. It just works?

MacPorts and /opt/local on Catalina and Big Sur read only volumes

[Tabitha McNerney]

Hi all,

I haven't installed a fresh MacPorts system in quite some time but will
soon be doing so on a few Macs one running Catalina and the other Big Sur.
Starting with Catalina, the root volume / is read-only so how do the
MacPorts package installers set things up such that /opt/local can remain
the default path to MacPorts for both read and write functionality on
Catalina and Big Sur? Do the MacPorts package installers make use of
Apple's new bi-directional firmlinks capability defined in
/etc/synthetic.conf as also described on this page?

https://derflounder.wordpress.com/2020/01/18/creating-root-level-directories-and-symbolic-links-on-macos-catalina/

Thank you.

-TM

Re: does osxfuse and encfs work in 10.15 (catalina)?

[Ryan Schmidt]

On Apr 9, 2021, at 07:33, Uwe Brauer wrote:

> I started to use a macbook air running catalina (10.15) and installed
> first of all fink. 
> 
> It took some time to install encfs and osxfuse (currently version 2.7)
> however when I want to use encfs on a specific directory I obtain 
> 
> 
> ,
> [+]
> | EncFS Password: 
> | /opt/sw/lib/osxfusefs.fs/Support/osxfusefs.kext failed to load -
> | (libkern/kext) not loadable (reason unspecified); check the
> | system/kernel logs for errors or try kextutil(8).
> | the OSXFUSE file system is not available (71)
> | fuse failed.  Common problems:
> |  - fuse kernel module not installed (modprobe fuse)
> |  - invalid options -- see usage message
> | EncFS Password: 
> | 
> `
> 
> According to the fink team this is (partially) caused by the fact that
> 10.15 locked down a lot of system features, including kernel extensions.
> 
> 
> So my question is, does encfs and osxfuse work in Macports?

As far as I know, osxfuse still cannot be installed using MacPorts on macOS 
10.15 or later.

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

does osxfuse and encfs work in 10.15 (catalina)?

[Uwe Brauer]

Hi 

I started to use a macbook air running catalina (10.15) and installed
first of all fink. 

It took some time to install encfs and osxfuse (currently version 2.7)
however when I want to use encfs on a specific directory I obtain 


,
[+]
| EncFS Password: 
| /opt/sw/lib/osxfusefs.fs/Support/osxfusefs.kext failed to load -
| (libkern/kext) not loadable (reason unspecified); check the
| system/kernel logs for errors or try kextutil(8).
| the OSXFUSE file system is not available (71)
| fuse failed.  Common problems:
|  - fuse kernel module not installed (modprobe fuse)
|  - invalid options -- see usage message
| EncFS Password: 
| 
`

According to the fink team this is (partially) caused by the fact that
10.15 locked down a lot of system features, including kernel extensions.


So my question is, does encfs and osxfuse work in Macports?

Thanks

Uwe Brauer 

Re: How can I make unbound's accepting of incoming network connections in application firewall in Catalina 'stick'?

[Gerben Wierda via macports-users]

Sorry, no go.

I found a solution on superuser with 0 votes ;-). 
https://superuser.com/a/940696/582447

It turns out that I just had to turn the firewall off and on again. It might 
have been a necessary last step to make it regenerate something, but after that 
step, a reboot (or just port unload/load cycle) will just allow unbound to 
startup and accept incoming connections without further panels

Note, that on my active production server I run Murus (PF configurator) and 
Vallum (configurator for the application-level firewall), which, though 
somewhat hard to work with sometimes, work well in configuring this.

Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
R&A Enterprise Architecture <https://ea.rna.nl/> (main site)
Book: Chess and the Art of Enterprise Architecture <https://ea.rna.nl/the-book/>
Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>

> On 15 Mar 2021, at 02:17, Steven Smith  wrote:
> 
> Just turn off your firewall! 😝
> 
> Seriously, the macOS firewall is an Application firewall. If that suits your 
> risk profile, you can control it through the command line:
> 
> /usr/libexec/ApplicationFirewall/socketfilterfw -h
> 
> Port- and packet-based filtering is handled by pfctl, and that’s a lot more 
> flexible than the macOS application firewall.
> 
>> On Mar 14, 2021, at 20:55, Gerben Wierda via macports-users 
>>  wrote:
>> 
>> I am running an extensive MacPorts (with postfix, dovecot, nginx, minion, 
>> etc.) on my macOS Server, which is still running macOS Mojave.
>> 
>> On one of the other Macs, running macOS Catalina, I run a backup unbound 
>> caching nameserver. This also offers me a way to do some minimal testing of 
>> the MacPorts setup on a more recent version of macOS (as a preparation for 
>> upgrading the Mojave system when Apple stops supporting it)
>> 
>> The unbound on macOS Catalina runs fine, except for one thing. After a 
>> reboot, unbound will not accept incoming connections until I have logged in 
>> an answer the application firewalls’ question:
>> 
>> Do you want the application “unbound” to accept incoming network connections?
>> Clicking Deny may limit the application’s behaviour. This setting can be 
>> changed in the Firewall pane of Security & Privacy preferences.
>> 
>> I can answer yes, check the entry in the application firewall (set to yes, 
>> accept, even before I allow it through the panel). But even if it is set to 
>> accept incoming connections, after a reboot I need to log in and answer 
>> again via the GUI before it accepts. Setting this in the Application 
>> firewall doesn’t ’stick’ for some reason.
>> 
>> This is not acceptable behaviour if I ever upgrade my Mojave Server, as that 
>> one must be able to do unsupervised reboots/running without any login.
>> 
>> Is there something special in Catalina I must do? Or is this expected 
>> behaviour?
>> 
>> Thanks,
>> 
>> Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
>> R&A Enterprise Architecture <https://ea.rna.nl/> (main site)
>> Book: Chess and the Art of Enterprise Architecture 
>> <https://ea.rna.nl/the-book/>
>> Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>
>> 

Re: How can I make unbound's accepting of incoming network connections in application firewall in Catalina 'stick'?

[Steven Smith]

Just turn off your firewall! 😝

Seriously, the macOS firewall is an Application firewall. If that suits your 
risk profile, you can control it through the command line:

/usr/libexec/ApplicationFirewall/socketfilterfw -h

Port- and packet-based filtering is handled by pfctl, and that’s a lot more 
flexible than the macOS application firewall.

> On Mar 14, 2021, at 20:55, Gerben Wierda via macports-users 
>  wrote:
> I am running an extensive MacPorts (with postfix, dovecot, nginx, minion, 
> etc.) on my macOS Server, which is still running macOS Mojave.
> 
> On one of the other Macs, running macOS Catalina, I run a backup unbound 
> caching nameserver. This also offers me a way to do some minimal testing of 
> the MacPorts setup on a more recent version of macOS (as a preparation for 
> upgrading the Mojave system when Apple stops supporting it)
> 
> The unbound on macOS Catalina runs fine, except for one thing. After a 
> reboot, unbound will not accept incoming connections until I have logged in 
> an answer the application firewalls’ question:
> 
> Do you want the application “unbound” to accept incoming network connections?
> Clicking Deny may limit the application’s behaviour. This setting can be 
> changed in the Firewall pane of Security & Privacy preferences.
> 
> I can answer yes, check the entry in the application firewall (set to yes, 
> accept, even before I allow it through the panel). But even if it is set to 
> accept incoming connections, after a reboot I need to log in and answer again 
> via the GUI before it accepts. Setting this in the Application firewall 
> doesn’t ’stick’ for some reason.
> 
> This is not acceptable behaviour if I ever upgrade my Mojave Server, as that 
> one must be able to do unsupervised reboots/running without any login.
> 
> Is there something special in Catalina I must do? Or is this expected 
> behaviour?
> 
> Thanks,
> 
> Gerben Wierda (LinkedIn)
> R&A Enterprise Architecture (main site)
> Book: Chess and the Art of Enterprise Architecture
> Book: Mastering ArchiMate


smime.p7s
Description: S/MIME cryptographic signature

Re: How can I make unbound's accepting of incoming network connections in application firewall in Catalina 'stick'?

[Gerben Wierda via macports-users]

It seems to be a code signing issue for /opt/local/sbin/unbound, but I haven’t 
found out how to get rid of it and MacPorts doesn’t handle it itself (i.e. 
forces the app to end into a good state or warn why it can’t do it).

Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
R&A Enterprise Architecture <https://ea.rna.nl/> (main site)
Book: Chess and the Art of Enterprise Architecture <https://ea.rna.nl/the-book/>
Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>

> On 15 Mar 2021, at 01:55, Gerben Wierda via macports-users 
>  wrote:
> 
> I am running an extensive MacPorts (with postfix, dovecot, nginx, minion, 
> etc.) on my macOS Server, which is still running macOS Mojave.
> 
> On one of the other Macs, running macOS Catalina, I run a backup unbound 
> caching nameserver. This also offers me a way to do some minimal testing of 
> the MacPorts setup on a more recent version of macOS (as a preparation for 
> upgrading the Mojave system when Apple stops supporting it)
> 
> The unbound on macOS Catalina runs fine, except for one thing. After a 
> reboot, unbound will not accept incoming connections until I have logged in 
> an answer the application firewalls’ question:
> 
> Do you want the application “unbound” to accept incoming network connections?
> Clicking Deny may limit the application’s behaviour. This setting can be 
> changed in the Firewall pane of Security & Privacy preferences.
> 
> I can answer yes, check the entry in the application firewall (set to yes, 
> accept, even before I allow it through the panel). But even if it is set to 
> accept incoming connections, after a reboot I need to log in and answer again 
> via the GUI before it accepts. Setting this in the Application firewall 
> doesn’t ’stick’ for some reason.
> 
> This is not acceptable behaviour if I ever upgrade my Mojave Server, as that 
> one must be able to do unsupervised reboots/running without any login.
> 
> Is there something special in Catalina I must do? Or is this expected 
> behaviour?
> 
> Thanks,
> 
> Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
> R&A Enterprise Architecture <https://ea.rna.nl/> (main site)
> Book: Chess and the Art of Enterprise Architecture 
> <https://ea.rna.nl/the-book/>
> Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>
> 

How can I make unbound's accepting of incoming network connections in application firewall in Catalina 'stick'?

[Gerben Wierda via macports-users]

I am running an extensive MacPorts (with postfix, dovecot, nginx, minion, etc.) 
on my macOS Server, which is still running macOS Mojave.

On one of the other Macs, running macOS Catalina, I run a backup unbound 
caching nameserver. This also offers me a way to do some minimal testing of the 
MacPorts setup on a more recent version of macOS (as a preparation for 
upgrading the Mojave system when Apple stops supporting it)

The unbound on macOS Catalina runs fine, except for one thing. After a reboot, 
unbound will not accept incoming connections until I have logged in an answer 
the application firewalls’ question:

Do you want the application “unbound” to accept incoming network connections?
Clicking Deny may limit the application’s behaviour. This setting can be 
changed in the Firewall pane of Security & Privacy preferences.

I can answer yes, check the entry in the application firewall (set to yes, 
accept, even before I allow it through the panel). But even if it is set to 
accept incoming connections, after a reboot I need to log in and answer again 
via the GUI before it accepts. Setting this in the Application firewall doesn’t 
’stick’ for some reason.

This is not acceptable behaviour if I ever upgrade my Mojave Server, as that 
one must be able to do unsupervised reboots/running without any login.

Is there something special in Catalina I must do? Or is this expected behaviour?

Thanks,

Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
R&A Enterprise Architecture <https://ea.rna.nl/> (main site)
Book: Chess and the Art of Enterprise Architecture <https://ea.rna.nl/the-book/>
Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>

Re: Catalina: accepting incoming connections on unbound does not survive a reboot

[Bill Cole]

On 14 Jan 2021, at 18:50, Tom wrote:


Have you tried Lulu or Little Snitch?


I've used both on various versions through 10.14. It is my understanding 
that due to Apple exempting their own software from the Network 
Extension Framework, both are hobbled on 10.15+, but that with 11.2 they 
will be reversing that choice.


My issues with modern macOS for server applications are mostly with the 
broken logging and the difficulty of stripping down the operational 
environment to just what's needed on a Mac that doesn't normally 
function as a personal computer.


Disabling the built-in firewall entirely may be your only solution. I 
am not sure because I have not bothered trying to make any macOS 
newer than El Capitan usable as a server. Life is short and FreeBSD 
exists.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Catalina: accepting incoming connections on unbound does not survive a reboot

[Bill Cole]

On 13 Jan 2021, at 8:26, Gerben Wierda via macports-users wrote:

I did not have this problem under Mojave, but since I have upgraded I 
do.


I am running a backup nameserver (in my split-DNS setup) on a mac 
desktop (unbound via MacPorts). After a reboot, the first user to log 
in gets a panel from the firewall with the question to allow incoming 
connections for unbound. System administrator user name and password 
are  given and incoming connections are then accepted. But after a 
reboot I have to do this again.


Yes. Because modern macOS is unfit for server applications. Apple 
started making design choices circa Sierra aimed at converging it with 
iOS, for reasons that make sense for personal computers but without 
regard to how servers would be affected.


Historically it has been possible to make specific persistent exceptions 
using the Firewall panel of the Security preferences pane and supposedly 
this still can be done on Catalina (see 
https://www.dummies.com/computers/macs/macbook/how-to-customize-your-macbooks-catalina-firewall/) 
but I have not tried that and it may not work for software that is not 
packaged as a macOS application. You definitely should disable "stealth 
mode" in that panel.


Disabling the built-in firewall entirely may be your only solution. I am 
not sure because I have not bothered trying to make any macOS newer than 
El Capitan usable as a server. Life is short and FreeBSD exists.





--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Catalina: accepting incoming connections on unbound does not survive a reboot

[Gerben Wierda via macports-users]

I did not have this problem under Mojave, but since I have upgraded I do.

I am running a backup nameserver (in my split-DNS setup) on a mac desktop 
(unbound via MacPorts). After a reboot, the first user to log in gets a panel 
from the firewall with the question to allow incoming connections for unbound. 
System administrator user name and password are  given and incoming connections 
are then accepted. But after a reboot I have to do this again.

This worries me. My main server (stilll on Mojave until I have enough 
confidence in MacPorts under Catalina to upgrade) must be able to survive a 
reboot without any user interaction via the GUI (i.e. when I am away from the 
physical location).

I wonder if it has anything to do with how unbound has been installed via 
MacPorts.

Any tips?

Thanks,

Gerben

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

> On Nov 18, 2020, at 10:39, Peter Hancock wrote:
> 
> On 13/11/2020 10:42, Ryan Schmidt wrote:
>> On macOS 10.15, you can avoid even more problems by limiting yourself to 
>> Xcode 11.7 and the Xcode 11.5 version of the command line tools. Upgrading 
>> to Xcode 12 or the Xcode 12 version of the command line tools will cause 
>> some ports to fail to build with implicit declaration of function errors or 
>> other errors that are a consequence of earlier implicit declaration of 
>> function errors. This problem is pervasive and although we have fixed many 
>> ports already, there are many many more that have yet to be identified and 
>> fixed.
> 
> Im on:
> Catalina 10.15.7, with Xcode 12.2 (12B45b).
> "pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version" gives 
> "version: 12.2.0.0.1.1604628099"
> 
> I have encountered "This problem".
> It was in the port "man" (that I don't actually need, on reflection). 
> I found (and can't any longer...) a recent ticket on trac, closed, fixing (on 
> big Sur?) what looked like
> the same problem (an undefined use of uint_t in signal.h) but the new version 
> doesn't build for me. 
> I'll open a new ticket, with my build log, if that's the right thing to do.

The ticket about the implicit declaration of function error in the man port was:

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

I thought I fixed it, though I only tested on macOS 10.13.

The problem you're describing sounds different. uint_t is a type, not a 
function, so it wouldn't be an implicit declaration of function error. Please 
report the problem to us in a ticket and attach the main.log as usual.


> However, I'd like to ask for some general advice/guidance. 
> 1. My machine won't upgrade beyond Catalina.
> 2. I need (hopefully) only the Command Line Tools, and that for MacPorts. 
>   I seem to have receipts for a whole slew of ancient Xcodes, CLT's etc. It 
> would be a joy to 
>   consign them all to the Trash, and somehow to persuade "Software Updates" 
> to 
>   shutup scolding me to update to something useless and damaging.
>   (ie. causing macports to fail building things actually important to me.)
> 
> What version of the CLT's should I download and install from Apple's 
> developer site?
> They are described as, eg. "Command Line Tools for Xcode 11.5", suggesting 
> they are no
> good to me without Xcode 11.5. 
> 
> But would macports, reinstalled if advisable, likely work fine if I first 
> uninstall 
> and trash all the other stuff and just install that?
> (I anticipate dragging /Applications/Xcode.app" to the trash, and running a 
> script I
> found in /Library/Developer/3.0/uninstall-devtools.  I don't mind some 
> lingering
> debris if only Software Update will shutup.)

If you don't need Xcode 12 for other reasons outside of MacPorts, you can save 
yourself the trouble of encountering implicit declaration of function errors by 
downgrading to Xcode 11 and the Xcode 11 command line tools. You should always 
use as matched a set as possible. The last version of Xcode 11 was 11.7 and the 
last version of the Xcode 11 command line tools was 11.5, so those are the 
versions I recommend for Catalina. It's what we use on the Catalina buildbot 
worker. If you don't want to install any of the ports that require Xcode, then 
you don't need to install Xcode.

If you install Xcode by downloading from the Apple developer site rather than 
using the App Store, I believe you will not be prompted about updating to the 
latest version.

I'm not sure how you would prevent software update from suggesting to you that 
you should update to the Xcode 12 version of the CLT. Deleting the receipt 
might do that, and in fact a bug in Catalina causes the receipt to be deleted 
automatically at some point, but that prevents MacPorts from being able to tell 
what version of the CLT you have installed, and MacPorts will ask you to 
reinstall the CLT so that the receipt is present.

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Peter Hancock]

On 13/11/2020 10:42, Ryan Schmidt wrote:
> On macOS 10.15, you can avoid even more problems by limiting yourself to 
> Xcode 11.7 and the Xcode 11.5 version of the command line tools. Upgrading to 
> Xcode 12 or the Xcode 12 version of the command line tools will cause some 
> ports to fail to build with implicit declaration of function errors or other 
> errors that are a consequence of earlier implicit declaration of function 
> errors. This problem is pervasive and although we have fixed many ports 
> already, there are many many more that have yet to be identified and fixed.

Im on:
Catalina 10.15.7, with Xcode 12.2 (12B45b).
"pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version" gives 
"version: 12.2.0.0.1.1604628099"

I have encountered "This problem".
It was in the port "man" (that I don't actually need, on reflection). 
I found (and can't any longer...) a recent ticket on trac, closed, fixing (on 
big Sur?) what looked like
the same problem (an undefined use of uint_t in signal.h) but the new version 
doesn't build for me. 
I'll open a new ticket, with my build log, if that's the right thing to do.

However, I'd like to ask for some general advice/guidance. 
1. My machine won't upgrade beyond Catalina.
2. I need (hopefully) only the Command Line Tools, and that for MacPorts. 
   I seem to have receipts for a whole slew of ancient Xcodes, CLT's etc. It 
would be a joy to 
   consign them all to the Trash, and somehow to persuade "Software Updates" to 
   shutup scolding me to update to something useless and damaging.
   (ie. causing macports to fail building things actually important to me.)

What version of the CLT's should I download and install from Apple's developer 
site?
They are described as, eg. "Command Line Tools for Xcode 11.5", suggesting they 
are no
good to me without Xcode 11.5. 

But would macports, reinstalled if advisable, likely work fine if I first 
uninstall 
and trash all the other stuff and just install that?
(I anticipate dragging /Applications/Xcode.app" to the trash, and running a 
script I
found in /Library/Developer/3.0/uninstall-devtools.  I don't mind some lingering
debris if only Software Update will shutup.)

Re: Any reason not to update to Xcode 12.2 on Catalina?

[raf]

On Mon, Nov 16, 2020 at 06:45:17PM -0600, Ryan Schmidt 
 wrote:

> On Nov 16, 2020, at 17:32, raf wrote:
> 
> > On Sun, Nov 15, 2020 at 11:56:54AM -0600, Ryan Schmidt wrote:
> > 
> >> You should definitely never run with a mismatched set of Xcode and its
> >> command line tools. Either update the command line tools to the Xcode
> >> 12.2 version or downgrade Xcode to whatever it was before. Using Xcode
> >> 11.x and matching CLT on macOS 10.15 will keep you from encountering
> >> some build failures.
> > 
> > Hi,
> > 
> > I have "XCode 11.3 (11C29)" (on macos-10.14.6) and,
> > in its Preferences / Locations, it says
> > "Command Line Tools: XCode 11.3 (11C29)".
> > 
> > But pkgutil seems to say otherwise:
> > 
> >  $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
> >  version: 10.3.0.0.1.1562985497
> > 
> > I haven't noticed any problem (yet), but that looks
> > like a mismatch. Should I upgrade the command line
> > tools anyway? Note that I never actually use the XCode
> > app itself, just the command line tools. I suppose the
> > answer is yes.
> > 
> > Also, is the XCode app mistaken about which version of
> > the command line tools are there, or is it just
> > referring to its embedded version of them?
> 
> This poorly-named Xcode preferences setting is showing you the same
> information as running "xcode-select -p". This tells you what you
> will be running if you run e.g. "clang" on the command line: will you
> get the one that's in Xcode or the one in the standalone command line
> tools package? In your case, it is telling you that you will get the
> one from Xcode 11.3.
> 
> As the pkgutil command shows, your standalone command line tools
> version is 10.3. Because this does not match your Xcode version, you
> should update it.
> 
> MacPorts will use the commands from Xcode if the port indicates that
> it requires that ("use_xcode yes") or if the standalone command line
> tools are not installed, otherwise it will use the commands from the
> command line tools. To avoid problems, make sure the two are the same
> version.

Hi Ryan,

Thanks for that. I have upgraded the command line tools to 11.3
so they match now.

cheers,
raf

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

On Nov 16, 2020, at 17:32, raf wrote:

> On Sun, Nov 15, 2020 at 11:56:54AM -0600, Ryan Schmidt wrote:
> 
>> You should definitely never run with a mismatched set of Xcode and its
>> command line tools. Either update the command line tools to the Xcode
>> 12.2 version or downgrade Xcode to whatever it was before. Using Xcode
>> 11.x and matching CLT on macOS 10.15 will keep you from encountering
>> some build failures.
> 
> Hi,
> 
> I have "XCode 11.3 (11C29)" (on macos-10.14.6) and,
> in its Preferences / Locations, it says
> "Command Line Tools: XCode 11.3 (11C29)".
> 
> But pkgutil seems to say otherwise:
> 
>  $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
>  version: 10.3.0.0.1.1562985497
> 
> I haven't noticed any problem (yet), but that looks
> like a mismatch. Should I upgrade the command line
> tools anyway? Note that I never actually use the XCode
> app itself, just the command line tools. I suppose the
> answer is yes.
> 
> Also, is the XCode app mistaken about which version of
> the command line tools are there, or is it just
> referring to its embedded version of them?

This poorly-named Xcode preferences setting is showing you the same information 
as running "xcode-select -p". This tells you what you will be running if you 
run e.g. "clang" on the command line: will you get the one that's in Xcode or 
the one in the standalone command line tools package? In your case, it is 
telling you that you will get the one from Xcode 11.3.

As the pkgutil command shows, your standalone command line tools version is 
10.3. Because this does not match your Xcode version, you should update it.

MacPorts will use the commands from Xcode if the port indicates that it 
requires that ("use_xcode yes") or if the standalone command line tools are not 
installed, otherwise it will use the commands from the command line tools. To 
avoid problems, make sure the two are the same version.

Re: Any reason not to update to Xcode 12.2 on Catalina?

[raf]

On Sun, Nov 15, 2020 at 11:56:54AM -0600, Ryan Schmidt 
 wrote:

> You should definitely never run with a mismatched set of Xcode and its
> command line tools. Either update the command line tools to the Xcode
> 12.2 version or downgrade Xcode to whatever it was before. Using Xcode
> 11.x and matching CLT on macOS 10.15 will keep you from encountering
> some build failures.

Hi,

I have "XCode 11.3 (11C29)" (on macos-10.14.6) and,
in its Preferences / Locations, it says
"Command Line Tools: XCode 11.3 (11C29)".

But pkgutil seems to say otherwise:

  $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version
  version: 10.3.0.0.1.1562985497

I haven't noticed any problem (yet), but that looks
like a mismatch. Should I upgrade the command line
tools anyway? Note that I never actually use the XCode
app itself, just the command line tools. I suppose the
answer is yes.

Also, is the XCode app mistaken about which version of
the command line tools are there, or is it just
referring to its embedded version of them?

cheers,
raf

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

Please keep the discussion on the mailing list by using the Reply All button in 
your mail program.


On Nov 15, 2020, at 11:18, Kevin Horton wrote:

> Caution - It looks like some recent macOS update fiddled with the preferences 
> in Software Update.  I found this morning that XCode on one Mac had been 
> unexpectedly updated to v12.2, and I found the box ticked for "Install app 
> updates from the App Store" in System Preferences -> Software Update -> 
> Advanced.  I managed to catch this before the second Mac had updated XCode

Apple loves to push automatic updates on users, which is often great, but in 
the case of Xcode and its command line tools it's not always desirable.


> Now one of my Macs is running Catalina, with XCode 12.2, but without having 
> upgraded the Command Line Tools.  And I ran "sudo port selfupdate; sudo port 
> upgrade outdated" before I discovered that XCode had been updated.
> 
> What is my best path forward?  Should I downgrade XCode?  Update the machine 
> to Big Sur?  Just leave it as is and let the MacPorts team work on ports for 
> a few weeks, then upgrade to Big Sur?

You should definitely never run with a mismatched set of Xcode and its command 
line tools. Either update the command line tools to the Xcode 12.2 version or 
downgrade Xcode to whatever it was before. Using Xcode 11.x and matching CLT on 
macOS 10.15 will keep you from encountering some build failures.

You don't have the option of using Xcode 11.x on Big Sur, so you can't avoid 
those build failures there; you have to wait for us to fix them. So if you want 
to avoid problems, don't upgrade to Big Sur yet.

Re: Any reason not to update to Xcode 12.2 on Catalina?

[Ryan Schmidt]

On Nov 12, 2020, at 23:08, Richard L. Hamilton wrote:

> One or two times past, an Xcode version around the time of a new OS release 
> has been a problem on the older OS.
> 
> I don't see anything likely to be that way with Xcode 12.2 (and MacPorts) on 
> Catalina, but I'm looking for alternative opinions; reverting is a nuisance.
> 
> I'm in no hurry for Big Sur at this point; maybe I'll wait for the .1 or .2 
> of it, unless a compelling reason to update emerges.
> 

Xcode 12.0 contains only the macOS 10.15 SDK. As such, it is suitable for using 
with macOS 10.15. I believe Xcode 12.1 was the same.

Xcode 12.2 contains only the macOS 11 SDK. As such, it has the potential to 
cause problems when building some software on macOS 10.15 and you would be 
safer to stick with Xcode 12.1. For software that does not require Xcode to 
build, you can mitigate the problem by installing the Command Line Tools for 
Xcode 12.2, because it contains both the macOS 10.15 SDK and the macOS 11 SDK. 
For software that does require Xcode to build, with Xcode 12.2 on macOS 10.15, 
you would be at the mercy of the developers of that software having written it 
correctly to anticipate differences between the SDK version and the OS version, 
which not all developers do correctly.

(Xcode 12.0 betas contained the macOS 11 SDK, but it was changed back to the 
macOS 10.15 SDK when Xcode 12.0 final was released, presumably because macOS 11 
was not released yet.)

On macOS 10.15, you can avoid even more problems by limiting yourself to Xcode 
11.7 and the Xcode 11.5 version of the command line tools. Upgrading to Xcode 
12 or the Xcode 12 version of the command line tools will cause some ports to 
fail to build with implicit declaration of function errors or other errors that 
are a consequence of earlier implicit declaration of function errors. This 
problem is pervasive and although we have fixed many ports already, there are 
many many more that have yet to be identified and fixed.

Any reason not to update to Xcode 12.2 on Catalina?

[Richard L. Hamilton]

One or two times past, an Xcode version around the time of a new OS release has 
been a problem on the older OS.

I don't see anything likely to be that way with Xcode 12.2 (and MacPorts) on 
Catalina, but I'm looking for alternative opinions; reverting is a nuisance.

I'm in no hurry for Big Sur at this point; maybe I'll wait for the .1 or .2 of 
it, unless a compelling reason to update emerges.

Re: Catalina xcode-select --install and MacPorts installation

[Fielding, Eric J (US 329A) via macports-users]

Thanks. Maybe there is something about the mobile device management setup my 
employer uses that changes how the installations work.

On 10/29/20, 03:44, "Ryan Schmidt"  wrote:



On Oct 28, 2020, at 02:31, Fielding, Eric J (US 329A) wrote:

> I just upgraded my MacBook to Catalina 10.15.7 from 10.14.6 and I 
installed the latest Xcode 12.1. I started Xcode and agreed for it to install 
required components. When I tried to run “xcode-select –install” it asked me to 
agree to the license for the command-line tools and tried to install but then 
said “Can’t install the software because it is not currently available from the 
Software Update server.” I went to the Software Update control panel and it 
said that it had an update for my command-line tools, and I told it to go ahead 
and update them. After a while, it said that the command-line tools are no 
longer required or something like that.
>  
> I decided to go ahead and try to install MacPorts with the Catalina 
MacPorts installer and it showed me the license, asked about the installation 
type and destination, but then when it got to the install step it says “Waiting 
for other installations to complete”. I don’t think I have any other 
installations still going on. Wait, after twenty minutes, it now says it is 
“running package scripts” and then finished. I guess it was installing 
something after all.
>  
> Maybe the Xcode installation instructions need an update for Catalina?
>  

As far as I know, the installation instructions are correct, and your 
experience is unique and I cannot explain it.

Re: Catalina xcode-select --install and MacPorts installation

[Ryan Schmidt]

On Oct 28, 2020, at 02:31, Fielding, Eric J (US 329A) wrote:

> I just upgraded my MacBook to Catalina 10.15.7 from 10.14.6 and I installed 
> the latest Xcode 12.1. I started Xcode and agreed for it to install required 
> components. When I tried to run “xcode-select –install” it asked me to agree 
> to the license for the command-line tools and tried to install but then said 
> “Can’t install the software because it is not currently available from the 
> Software Update server.” I went to the Software Update control panel and it 
> said that it had an update for my command-line tools, and I told it to go 
> ahead and update them. After a while, it said that the command-line tools are 
> no longer required or something like that.
>  
> I decided to go ahead and try to install MacPorts with the Catalina MacPorts 
> installer and it showed me the license, asked about the installation type and 
> destination, but then when it got to the install step it says “Waiting for 
> other installations to complete”. I don’t think I have any other 
> installations still going on. Wait, after twenty minutes, it now says it is 
> “running package scripts” and then finished. I guess it was installing 
> something after all.
>  
> Maybe the Xcode installation instructions need an update for Catalina?
>  

As far as I know, the installation instructions are correct, and your 
experience is unique and I cannot explain it.

Catalina xcode-select --install and MacPorts installation

[Fielding, Eric J (US 329A) via macports-users]

I just upgraded my MacBook to Catalina 10.15.7 from 10.14.6 and I installed the 
latest Xcode 12.1. I started Xcode and agreed for it to install required 
components. When I tried to run “xcode-select –install” it asked me to agree to 
the license for the command-line tools and tried to install but then said 
“Can’t install the software because it is not currently available from the 
Software Update server.” I went to the Software Update control panel and it 
said that it had an update for my command-line tools, and I told it to go ahead 
and update them. After a while, it said that the command-line tools are no 
longer required or something like that.

I decided to go ahead and try to install MacPorts with the Catalina MacPorts 
installer and it showed me the license, asked about the installation type and 
destination, but then when it got to the install step it says “Waiting for 
other installations to complete”. I don’t think I have any other installations 
still going on. Wait, after twenty minutes, it now says it is “running package 
scripts” and then finished. I guess it was installing something after all.

Maybe the Xcode installation instructions need an update for Catalina?

++Eric

Re: Xcode 12 on Catalina?

[Christopher Chavez]

> I've been putting off the upgrade to XCode 12 for a while, since I kinda
> got burned by the upgrade from 10 to 11. I haven't seen any reports of
> problems with the new version, but I thought I'd ask -- any reason not to
> upgrade at this point?

It seems the most frequently encountered issue so far is how implicit function declarations are now considered errors rather than warnings; reportedly this is done because of ABI requirements of macOS on ARM 64-bit. There have been tickets steadily reported every few days for affected ports. Sometimes these are due to forgetting to include a header file and is easy to fix (sometimes upstream has already began fixing them). Other times it is "old-school" C programming habits of intentionally declaring functions implicitly, and is more tedious/difficult to fix particularly without upstream developer involvement.

Christopher A. Chavez

Re: Xcode 12 on Catalina?

[Richard L. Hamilton]

I had a problem recently that may have been due to Xcode 12, with the 
convertlit port, where the code was missing some include files and declarations 
that really should have been there. That was fixed, and I'm ok since then with 
Xcode 12 on Catalina. There may have been some earlier problems, but that one 
was recent enough that I remember it.

However, while I have a lot (1630) of ports installed, I certainly have NOT 
built every port, let alone every variant of every port. So it's likely there 
are some problems yet to be found.

If you're paranoid, check for tickets on all your ports; or at least, maybe not 
the libraries that most people would have to install anyway, but for the ports 
likely to be less widely used.

There's an option to let MacPorts collect some statistics; I don't do it, 
because I don't give away info for only indirect benefit. If I could obtain a 
periodic report showing approximate usage levels for (only) the ports I had 
installed, and maybe have a script to do a bulk ticket query for the least-used 
ones, that would give me some direct benefit, an awareness of where the risks 
were likeliest in something like an Xcode update, so I could decide whether any 
of those were show-stoppers.

Given the limited number of people involved and that it's free, everyone is a 
bit the guinea pig. Although it might be nice if build farm failures 
automatically generated tickets, but doing that in a way that didn't generate 
too many duplicate/spammy tickets and was really useful, might be harder than 
just saying it'd be nice. :-)

Usually a newer version of Xcode is a minor-to-moderate risk; and within a 
month or two at most, is not much of a problem. As a last resort, it's usually 
possible to remove it and re-install the older version from a download rather 
than from the Mac App store. So if I had only one system, or didn't have one I 
was willing to take risks on, I'd be slow to update Xcode; but where the risk 
was acceptable, I'd probably update within a week, just so as not to see the 
badge on the App Store icon.

Things could get interesting for at least awhile for upcoming Apple Silicon 
(ARM architecture) systems. But this isn't the first transition; there was 
PowerPC to Intel, and getting rid of 32-bit for Catalina. There's some breakage 
on the latter, insofar as the Wine port may not be ready yet (without some 
tricky additional work, 64-bit Wine could only run 64-bit Windows executables), 
but mostly the record has been good, if one considers the very limited 
resources for MacPorts.



> On Oct 15, 2020, at 22:32, Richard Cobbe  wrote:
> 
> I've been putting off the upgrade to XCode 12 for a while, since I kinda
> got burned by the upgrade from 10 to 11.  I haven't seen any reports of
> problems with the new version, but I thought I'd ask -- any reason not to
> upgrade at this point?
> 
> Thanks,
> 
> Richard
> 

Xcode 12 on Catalina?

[Richard Cobbe]

I've been putting off the upgrade to XCode 12 for a while, since I kinda
got burned by the upgrade from 10 to 11.  I haven't seen any reports of
problems with the new version, but I thought I'd ask -- any reason not to
upgrade at this point?

Thanks,

Richard

Re: freeciv SDL - blank screen on Mojave/Catalina

[Ryan Schmidt]

On Nov 23, 2019, at 10:37, Dennis van der Burg wrote:

> Since upgrading to Mojave, when doing a fresh MacPorts install and then 
> installing freeciv (SDL client) and clicking on the Apps>MacPorts>Freeciv 
> icon, only a blank screen opens instead of a screen with the game running in 
> it.
> 
> Has anyone else seen this too? Any ideas how to solve this? This package is 
> currently listed on the MacPorts website as having no maintainer.

I believe this is a libsdl bug on Mojave and later for which I have submitted a 
PR which the maintainer of libsdl has not yet accepted:

https://github.com/macports/macports-ports/pull/7314

After your email, he modified freeciv so that on newer OS versions it uses 
libsdl2 which presumably does not have the same bug.

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

Xcode 11.5 on Catalina FYI

[Richard L. Hamilton]

While I haven't yet updated many ports with it, so far I've seen no problems 
with Xcode 11.5 on Catalina.

In other words, as yet I don't regret updating to it. :-)

Re: upgrade to osx 10.15 catalina

[Ryan Schmidt]

> On 09/01/2020 1:50 pm, joerg van den hoff wrote:
>> I had to upgrade to 10.15 (wanted to postpone this further but ...) and 
>> recall that there were many reports over the last months of problems with 
>> subsequent macports upgrade, recommendations to use previous xcode releases 
>> with catalina and assorted package specific problems simply not being 
>> solvable right now.
>> I have looked at the mail archive and macports webpage but have not found a 
>> clear recommendation or statement what the current situation (as of jan 
>> 2020) is.
>> so simple question: is it save/recommended to use current xcode (11.3) when 
>> doing the usual macports migration routine? are there guaranteed problems in 
>> certain packages/areas? or is everything back
>> to normal (most things will work, some might not...)?

There were some new features introduced in Xcode 11 which caused some problems 
for some ports. I believe most of these are resolved in Xcode 11.3 so you 
should use the latest version of Xcode 11 with Catalina. You cannot use Xcode 
versions earlier than 11 with Catalina.


On Jan 9, 2020, at 07:59, Chris Jones wrote:
> 
> At the end of the day though only you know which ports you really care about, 
> and cannot live without, so you need to do your homework yourself. Identified 
> those ports and then check their status at
> 
> https://ports.macports.org/

Note that the big green or red status boxes you see there do not necessarily 
correspond to the currently-available version of the port; see 
https://github.com/macports/macports-webapp/issues/135

Re: upgrade to osx 10.15 catalina

[Chris Jones]

Hi,

I would say the situation with 10.15 is now similar to other OSes. Some 
things work, some things do not. There are also some clear cases of 
things not working, and cannot/willnot be fixed, such as 32 bit support.


At the end of the day though only you know which ports you really care 
about, and cannot live without, so you need to do your homework 
yourself. Identified those ports and then check their status at


https://ports.macports.org/

Finally, as with any major OS update, I strongly recommend making a full 
bootable clone of your current system, before doing anything. Then, if 
worst comes to work, reverting back is trivial. I recommend this for any 
OS update, not at all specific to MacPorts...


Chris

On 09/01/2020 1:50 pm, joerg van den hoff wrote:
I had to upgrade to 10.15 (wanted to postpone this further but ...) and 
recall that there were many reports over the last months of problems 
with subsequent macports upgrade, recommendations to use previous xcode 
releases with catalina and assorted package specific problems simply not 
being solvable right now.


I have looked at the mail archive and macports webpage but have not 
found a clear recommendation or statement what the current situation (as 
of jan 2020) is.


so simple question: is it save/recommended to use current xcode (11.3) 
when doing the usual macports migration routine? are there guaranteed 
problems in certain packages/areas? or is everything back

to normal (most things will work, some might not...)?

thank you

upgrade to osx 10.15 catalina

[joerg van den hoff]

I had to upgrade to 10.15 (wanted to postpone this further but ...) and recall that there were many 
reports over the last months of problems with subsequent macports upgrade, recommendations to use 
previous xcode releases with catalina and assorted package specific problems simply not being 
solvable right now.


I have looked at the mail archive and macports webpage but have not found a clear recommendation or 
statement what the current situation (as of jan 2020) is.


so simple question: is it save/recommended to use current xcode (11.3) when doing the usual macports 
migration routine? are there guaranteed problems in certain packages/areas? or is everything back

to normal (most things will work, some might not...)?

thank you

Re: ffmpeg Fails After MacPorts Migration to Catalina Version

[Michael Newman via macports-users]

There are two recent tickets which, I believe, involve the same error:

ffmpeg and ffmpeg-devel immediately crash with segfault 11 when input is mp4:
https://trac.macports.org/ticket/59750 

ffmpeg @4.2.1 crash using -vcodec libx264:
https://trac.macports.org/ticket/59390 

Re: ffmpeg Fails After MacPorts Migration to Catalina Version

[Michael Newman via macports-users]

These work:

/usr/local/bin/avconv -y -r 10 -i $inpath -r 10 -vcodec libx264 -q:v 3 $vfile;

/usr/local/bin/ffmpeg -y -r 10 -i $inpath -r 10 -vcodec libx264 -q:v 3 $vfile;

This doesn’t:

/opt/local/bin/ffmpeg -y -r 10 -i $inpath -r 10 -vcodec libx264 -q:v 3 $vfile;

Both ffmpegs are version 4.2.1

It seems to be a MacPorts issue.

Re: ffmpeg Fails After MacPorts Migration to Catalina Version

[Andrew Udvare]

> On 2019-12-13, at 23:51, Michael Newman via macports-users 
>  wrote:
> 
> I tried uninstalling all ports and reinstalling again. That didn’t work.
> 
> I did manage to get my time-lapse videos working with avconv.

I tested a similar ffmpeg command and it fails with the same segfault. This is 
a bug in ffmpeg.

https://trac.ffmpeg.org/ticket/8073

As a workaround, the port could use --extra-cflags="-fno-stack-check" and it 
would work, I guess.

Andrew

Re: ffmpeg Fails After MacPorts Migration to Catalina Version

[Michael Newman via macports-users]

I tried uninstalling all ports and reinstalling again. That didn’t work.

I did manage to get my time-lapse videos working with avconv.

Re: ffmpeg Fails After MacPorts Migration to Catalina Version

[Michael Newman via macports-users]

I saved the version of ffmpeg that was built before I migrated and which worked 
fine before migration.

It also now fails with the same error message. So, I think there’s something 
else going on here

> On Dec 14, 2019, at 08:16, Andrew Udvare  wrote:
> 
> It's built so it seems more likely this is a bug in ffmpeg.
> 
> Sent from my iPhone

Re: ffmpeg Fails After MacPorts Migration to Catalina Version

[Andrew Udvare]

It's built so it seems more likely this is a bug in ffmpeg.

Sent from my iPhone

> On Dec 13, 2019, at 18:56, Michael Newman  wrote:
> 
> I’m not positive, but I believe it was built from source. This is what I got 
> when I removed and reinstalled it:
> 
> MrMuscle:bin mnewman$ sudo port install ffmpeg
> --->  Computing dependencies for ffmpeg
> --->  Fetching archive for ffmpeg
> --->  Attempting to fetch ffmpeg-4.2.1_2+gpl2.darwin_19.x86_64.tbz2 from 
> http://lil.fr.packages.macports.org/ffmpeg
> --->  Attempting to fetch ffmpeg-4.2.1_2+gpl2.darwin_19.x86_64.tbz2 from 
> http://cph.dk.packages.macports.org/ffmpeg
> --->  Attempting to fetch ffmpeg-4.2.1_2+gpl2.darwin_19.x86_64.tbz2 from 
> http://jog.id.packages.macports.org/macports/packages/ffmpeg
> --->  Fetching distfiles for ffmpeg
> --->  Verifying checksums for ffmpeg
> --->  Extracting ffmpeg
> --->  Applying patches to ffmpeg
> --->  Configuring ffmpeg
> --->  Building ffmpeg
> --->  Staging ffmpeg into destroot
> --->  Installing ffmpeg @4.2.1_2+gpl2
> --->  Activating ffmpeg @4.2.1_2+gpl2
> --->  Cleaning ffmpeg
> --->  Updating database of binaries
> --->  Scanning binaries for linking errors
> --->  No broken files found.
> --->  No broken ports found.
> 
> 
>> On Dec 14, 2019, at 06:49, Andrew Udvare  wrote:
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>>> On Dec 13, 2019, at 18:28, Michael Newman via macports-users 
>>>>  wrote:
>>> 
>>> I’ve been using ffmpeg daily for several years to generate time lapse 
>>> videos from a series of JPEGs.
>>> 
>>> After I updated my 2017 iMac to Catalina, it still worked.
>>> 
>>> However, after migrating MacPorts to the Catalina version, it fails:
>>> 
>>> ./skyvideo.sh: line 38:  5438 Donecat $ipath
>>> 5439 Segmentation fault: 11  | /opt/local/bin/ffmpeg -f image2pipe 
>>> -framerate 10 -vcodec mjpeg -i - -vcodec libx264 -preset veryslow 
>>> -hide_banner -loglevel panic -r 10 -crf 28 -y -pix_fmt yuv420p "$vfile" >> 
>>> "$log"
>> 
>> Is this a premade binary or built from source? If it's a binary you should 
>> try building from source.
>> 
>> I'm not sure MacPorts provides a binary of ffmpeg.
>> 
>> Andrew
> 

Re: ffmpeg Fails After MacPorts Migration to Catalina Version

[Michael Newman via macports-users]

I’m not positive, but I believe it was built from source. This is what I got 
when I removed and reinstalled it:

MrMuscle:bin mnewman$ sudo port install ffmpeg
--->  Computing dependencies for ffmpeg
--->  Fetching archive for ffmpeg
--->  Attempting to fetch ffmpeg-4.2.1_2+gpl2.darwin_19.x86_64.tbz2 from 
http://lil.fr.packages.macports.org/ffmpeg
--->  Attempting to fetch ffmpeg-4.2.1_2+gpl2.darwin_19.x86_64.tbz2 from 
http://cph.dk.packages.macports.org/ffmpeg
--->  Attempting to fetch ffmpeg-4.2.1_2+gpl2.darwin_19.x86_64.tbz2 from 
http://jog.id.packages.macports.org/macports/packages/ffmpeg
--->  Fetching distfiles for ffmpeg
--->  Verifying checksums for ffmpeg
--->  Extracting ffmpeg
--->  Applying patches to ffmpeg
--->  Configuring ffmpeg
--->  Building ffmpeg
--->  Staging ffmpeg into destroot
--->  Installing ffmpeg @4.2.1_2+gpl2
--->  Activating ffmpeg @4.2.1_2+gpl2
--->  Cleaning ffmpeg
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.


> On Dec 14, 2019, at 06:49, Andrew Udvare  wrote:
> 
> 
> 
> Sent from my iPhone
> 
>> On Dec 13, 2019, at 18:28, Michael Newman via macports-users 
>>  wrote:
>> 
>> I’ve been using ffmpeg daily for several years to generate time lapse 
>> videos from a series of JPEGs.
>> 
>> After I updated my 2017 iMac to Catalina, it still worked.
>> 
>> However, after migrating MacPorts to the Catalina version, it fails:
>> 
>> ./skyvideo.sh: line 38:  5438 Donecat $ipath
>>  5439 Segmentation fault: 11  | /opt/local/bin/ffmpeg -f image2pipe 
>> -framerate 10 -vcodec mjpeg -i - -vcodec libx264 -preset veryslow 
>> -hide_banner -loglevel panic -r 10 -crf 28 -y -pix_fmt yuv420p "$vfile" >> 
>> "$log"
> 
> Is this a premade binary or built from source? If it's a binary you should 
> try building from source.
> 
> I'm not sure MacPorts provides a binary of ffmpeg.
> 
> Andrew

Re: ffmpeg Fails After MacPorts Migration to Catalina Version

[Andrew Udvare]

Sent from my iPhone

> On Dec 13, 2019, at 18:28, Michael Newman via macports-users 
>  wrote:
> 
> I’ve been using ffmpeg daily for several years to generate time lapse videos 
> from a series of JPEGs.
> 
> After I updated my 2017 iMac to Catalina, it still worked.
> 
> However, after migrating MacPorts to the Catalina version, it fails:
> 
> ./skyvideo.sh: line 38:  5438 Donecat $ipath
>   5439 Segmentation fault: 11  | /opt/local/bin/ffmpeg -f image2pipe 
> -framerate 10 -vcodec mjpeg -i - -vcodec libx264 -preset veryslow 
> -hide_banner -loglevel panic -r 10 -crf 28 -y -pix_fmt yuv420p "$vfile" >> 
> "$log"

Is this a premade binary or built from source? If it's a binary you should try 
building from source.

I'm not sure MacPorts provides a binary of ffmpeg.

Andrew

ffmpeg Fails After MacPorts Migration to Catalina Version

[Michael Newman via macports-users]

I’ve been using ffmpeg daily for several years to generate time lapse videos 
from a series of JPEGs.

After I updated my 2017 iMac to Catalina, it still worked.

However, after migrating MacPorts to the Catalina version, it fails:

./skyvideo.sh: line 38:  5438 Donecat $ipath
  5439 Segmentation fault: 11  | /opt/local/bin/ffmpeg -f image2pipe 
-framerate 10 -vcodec mjpeg -i - -vcodec libx264 -preset veryslow -hide_banner 
-loglevel panic -r 10 -crf 28 -y -pix_fmt yuv420p "$vfile" >> "$log"

Version information:

MrMuscle:bin mnewman$ port -v
MacPorts 2.6.2
MrMuscle:bin mnewman$ ffmpeg -version
ffmpeg version 4.2.1 Copyright (c) 2000-2019 the FFmpeg developers

The MacOS Problem Report is here:

https://pastebin.com/G6cN0t7Y <https://pastebin.com/G6cN0t7Y>

I had saved a pre-migration version of ffmpeg that I know worked, but it now 
fails in the same way.

Re: problem migrating to catalina

[Ryan Schmidt]

Please remember to write to our new mailing list addresses at 
lists.macports.org, not the old address you used which was deprecated at the 
end of 2016.

The error in the log you attached is:

:info:build dyld: Library not loaded: /opt/local/lib/libcrypto.1.0.0.dylib
:info:build   Referenced from: /opt/local/lib/libxar.1.dylib
:info:build   Reason: image not found
:info:build fatal error: otool: fatal error in 
/opt/local/bin/llvm-objdump-mp-7.0

If you were using the current version of /opt/local/lib/libxar.1.dylib (which 
is provided by the xar port), it would have been linked with 
/opt/local/lib/libcrypto.1.1.dylib, not /opt/local/lib/libcrypto.1.0.0.dylib. 
This suggests you haven't followed the usual migration steps, which would have 
you uninstall all your ports before trying to install new ones. I myself often 
upgrade this way, but I'm comfortable reading the failure logs and figuring out 
what I need to do to proceed. In this case, if you want to continue to try to 
upgrade your ports piecemeal, what you need to do is upgrade xar first. But you 
may run into further problems after that. If you want to avoid that, follow the 
migration instructions.

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

Re: 32bit Docker containers in Catalina

[Ryan Schmidt]

On Nov 28, 2019, at 11:04, Ces VLC wrote:

> Should I be beware of difficulties at running 32bit Linux containers in the 
> macports docker in Catalina, or should the Catalina hypervisor be fine at 
> virtualizing 32bit code?

I know that the developers of Wine are having to do a lot of engineering to get 
32-bit Windows apps to run under Catalina, since Apple has thoroughly removed 
the ability to run any 32-bit code from Catalina. I don't know about Docker or 
Linux containers or the hypervisor, but I would not expect to be able to run 
32-bit anything on Catalina and later. Install Catalina on a volume that is not 
your main boot volume and try it out. If you have room on your main disk and it 
is APFS-formatted, you can easily create a new volume in Disk Utility that will 
share the free space, and if it doesn't work out, you can delete the volume 
later.

Re: problem migrating to catalina

[Comer Duncan]

Chris,

Thanks for the suggestion about bzip2. I have compresse with bzip2 and
am attaching herewith.

Comer

On Thu, Nov 28, 2019 at 1:06 PM Chris Jones  wrote:
>
>
>
> > On 28 Nov 2019, at 3:39 pm, Comer Duncan  wrote:
> >
> > I've migrated to catalina and  am having problem with building pango.
> > I've attached an edited version of the main.log, as the whole file was
> > deemed too big.  Please take a look and let me know what you think.
> > Thanks very much!
>
> You could have just compressed the log with bzip2 etc...
>
> >
> > Comer Duncan
> > 
>


main.log.bz2
Description: BZip2 compressed data

Re: problem migrating to catalina

[Chris Jones]

> On 28 Nov 2019, at 3:39 pm, Comer Duncan  wrote:
> 
> I've migrated to catalina and  am having problem with building pango.
> I've attached an edited version of the main.log, as the whole file was
> deemed too big.  Please take a look and let me know what you think.
> Thanks very much!

You could have just compressed the log with bzip2 etc...

> 
> Comer Duncan
> 

32bit Docker containers in Catalina

[Ces VLC]

Hi!

Should I be beware of difficulties at running 32bit Linux containers in the
macports docker in Catalina, or should the Catalina hypervisor be fine at
virtualizing 32bit code?

Thanks!

César
PS: Just found mingw-w64 just updated to 7.0.0 yay! Thanks a million Mojca!!

problem migrating to catalina

[Comer Duncan]

I've migrated to catalina and  am having problem with building pango.
I've attached an edited version of the main.log, as the whole file was
deemed too big.  Please take a look and let me know what you think.
Thanks very much!

Comer Duncan


duncan.migrate.to.cataline.summaryerrors
Description: Binary data

Catalina X11 xterm - cannot access ~/.Trash and /Volumes/* - Full Disk Access

[Justin Vallon]

Trying to get access in xterm to ~/.Trash and /Volumes/*, but Catalina
is blocking access.

* In SysPref/Sec&Priv/Privacy/Full Disk Access, remove "Terminal".
* Run Terminal, try "ls ~/.Trash" - "Operation not permitted"
* Back to Full Disk Access, "Terminal" is not present, but unchecked
* Enable "Terminal"
* Restart Terminal, try "ls ~/.Trash" - ok

Now for X11 / xterm:

* In xterm, try "ls ~/.Trash" - "Operation not permitted"
* Full Disk Access now shows an entry for "launchd_startx"
* Try enable "launchd_startx"
* xterm "ls ~/.Trash" - "Operation not permitted"
* Try granting FDA to:
  * X11 (drag the app)
  * /opt/local/bin/xterm
  * /bin/ls
  * /App/MacPorts/X11.app/Contents/MacOS/X11.bin (the real bin)

Can't get it to work.

Similar problem for any /Volumes/disk.  When I first tried in Terminal,
a security message said something like "Terminal.app" wants to access
removable disk [Deny] [Ok].  I clicked ok.  However, I don't see that
permission in System Prefs.

In xterm, cannot see /Volumes/disk, either.

Does anybody know any magic to fix this?

-- 
-Justin
justinval...@gmail.com

Re: Catalina installation problems

[Tarik Cicic]

Now, this is embarassing – it was the corporate firewall :/

Thank you for you assistance!  

Tarik

> On 26 Nov 2019, at 15:37, Pierre Malard  wrote:
> 
> Hi Tarik,
> 
>> Le 26 nov. 2019 à 13:49, Tarik Cicic > <mailto:tarik.ci...@gmail.com>> a écrit :
>> 
>> Hi Pierre,
>> 
>> normal rsync works fine “by hand” tested toward another server.
> 
> it would have been better to run the rsync from that same server rather than 
> another. The only proven is ... that works from the other server, nothing 
> about this Mac.
> 
>>I have no proxy configured, and my 
>> “/opt/local/etc/macports/macports.conf” is unmodified.
> 
> Ok
> 
>> 
>> Could it be that the file 
>> rsync.macports.org/macports/release/tarballs/base.tar 
>> <http://rsync.macports.org/macports/release/tarballs/base.tar> redirects to 
>> (in Erlangen?) simply is not there?  Do people normally use preinstalled 
>> rsync on Mac, or some more recent package? 
> 
> Do you see if the file exist? or the directory « /opt/local/…/tarballs »?
> Personally I use the old MacOS rsync. There is no problem.
> 
>> 
>> Thanks,
>> 
>>  Tarik
>> 
>>> On 26 Nov 2019, at 11:29, Pierre Malard >> <mailto:p...@teledetection.fr>> wrote:
>>> 
>>> Hi,
>>> 
>>> Did you try the rsync command « by hand » on a terminal session?
>>> An other way: is it a proxy between your PC and MacPorts? Global or 
>>> specific to MacPorts (file « /opt/local/etc/macports/macports.conf » and « 
>>> proxy » key)?
>>> 
>>>> Le 26 nov. 2019 à 11:20, Tarik Cicic >>> <mailto:tarik.ci...@gmail.com>> a écrit :
>>>> 
>>>> Hi,
>>>> 
>>>> I have been using Macports for years, and for first time have problems 
>>>> installing, after upgrade to MacOS 10.15 Catalina. 
>>>> 
>>>> Gray-MBP:~ tarik$ sudo port -d selfupdate
>>>> Password:
>>>> DEBUG: Copying /Users/tarik/Library/Preferences/com.apple.dt.Xcode.plist 
>>>> to /opt/local/var/macports/home/Library/Preferences
>>>> DEBUG: MacPorts sources location: 
>>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>>>  <http://rsync.macports.org/macports/release/tarballs>
>>>> --->  Updating MacPorts base sources using rsync
>>>> DEBUG: system: /usr/bin/rsync -rtzvl --delete-after 
>>>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>>>  
>>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>>>  <http://rsync.macports.org/macports/release/tarballs>
>>>> rsync: failed to connect to rsync.macports.org 
>>>> <http://rsync.macports.org/>: Operation timed out (60)
>>>> rsync error: error in socket IO (code 10) at 
>>>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54/rsync/clientserver.c(106)
>>>>  [receiver=2.6.9]
>>>> Command failed: /usr/bin/rsync -rtzvl --delete-after 
>>>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>>>  
>>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>>>  <http://rsync.macports.org/macports/release/tarballs>
>>>> Exit code: 10
>>>> Gray-MBP:~ tarik$ 
>>>> 
>>>> The site is available:
>>>> 
>>>> Gray-MBP:~ tarik$ ping rsync.macports.org <http://rsync.macports.org/>
>>>> PING ftp.rrze.uni-erlangen.de <http://ftp.rrze.uni-erlangen.de/> 
>>>> (131.188.12.211): 56 data bytes
>>>> 64 bytes from 131.188.12.211: icmp_seq=0 ttl=52 time=38.689 ms
>>>> 64 bytes from 131.188.12.211: icmp_seq=1 ttl=52 time=32.265 ms
>>>> 64 bytes from 131.188.12.211: icmp_seq=2 ttl=52 time=38.667 ms
>>>> ^C
>>>> --- ftp.rrze.uni-erlangen.de <http://ftp.rrze.uni-erlangen.de/> ping 
>>>> statistics ---
>>>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>>>> round-trip min/avg/max/stddev = 32.265/36.540/38.689/3.023 ms
>>>> 
>>>> Xcode Version 11.2.1 (11B500) and command line tools are installed.  Port 
>>>> version is 2.6.2.  Any suggestion is welcome!
>>>> 
>>>> Thanks,
>>>> 
>>>>Tarik
>>> 
>>> -- 
>>> Pierre Malard
>>> 
>>>   « Les utopies ne sont souvent que des vérités prématurées »
>>>  

Re: Catalina installation problems

[Pierre Malard]

Hi Tarik,

> Le 26 nov. 2019 à 13:49, Tarik Cicic  a écrit :
> 
> Hi Pierre,
> 
> normal rsync works fine “by hand” tested toward another server.

it would have been better to run the rsync from that same server rather than 
another. The only proven is ... that works from the other server, nothing about 
this Mac.

>I have no proxy configured, and my “/opt/local/etc/macports/macports.conf” 
> is unmodified.

Ok

> 
> Could it be that the file 
> rsync.macports.org/macports/release/tarballs/base.tar 
> <http://rsync.macports.org/macports/release/tarballs/base.tar> redirects to 
> (in Erlangen?) simply is not there?  Do people normally use preinstalled 
> rsync on Mac, or some more recent package?

Do you see if the file exist? or the directory « /opt/local/…/tarballs »?
Personally I use the old MacOS rsync. There is no problem.

> 
> Thanks,
> 
>   Tarik
> 
>> On 26 Nov 2019, at 11:29, Pierre Malard > <mailto:p...@teledetection.fr>> wrote:
>> 
>> Hi,
>> 
>> Did you try the rsync command « by hand » on a terminal session?
>> An other way: is it a proxy between your PC and MacPorts? Global or specific 
>> to MacPorts (file « /opt/local/etc/macports/macports.conf » and « proxy » 
>> key)?
>> 
>>> Le 26 nov. 2019 à 11:20, Tarik Cicic >> <mailto:tarik.ci...@gmail.com>> a écrit :
>>> 
>>> Hi,
>>> 
>>> I have been using Macports for years, and for first time have problems 
>>> installing, after upgrade to MacOS 10.15 Catalina.
>>> 
>>> Gray-MBP:~ tarik$ sudo port -d selfupdate
>>> Password:
>>> DEBUG: Copying /Users/tarik/Library/Preferences/com.apple.dt.Xcode.plist to 
>>> /opt/local/var/macports/home/Library/Preferences
>>> DEBUG: MacPorts sources location: 
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>>  <http://rsync.macports.org/macports/release/tarballs>
>>> --->  Updating MacPorts base sources using rsync
>>> DEBUG: system: /usr/bin/rsync -rtzvl --delete-after 
>>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>>  
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>>  <http://rsync.macports.org/macports/release/tarballs>
>>> rsync: failed to connect to rsync.macports.org 
>>> <http://rsync.macports.org/>: Operation timed out (60)
>>> rsync error: error in socket IO (code 10) at 
>>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54/rsync/clientserver.c(106)
>>>  [receiver=2.6.9]
>>> Command failed: /usr/bin/rsync -rtzvl --delete-after 
>>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>>  
>>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
>>>  <http://rsync.macports.org/macports/release/tarballs>
>>> Exit code: 10
>>> Gray-MBP:~ tarik$
>>> 
>>> The site is available:
>>> 
>>> Gray-MBP:~ tarik$ ping rsync.macports.org <http://rsync.macports.org/>
>>> PING ftp.rrze.uni-erlangen.de <http://ftp.rrze.uni-erlangen.de/> 
>>> (131.188.12.211): 56 data bytes
>>> 64 bytes from 131.188.12.211: icmp_seq=0 ttl=52 time=38.689 ms
>>> 64 bytes from 131.188.12.211: icmp_seq=1 ttl=52 time=32.265 ms
>>> 64 bytes from 131.188.12.211: icmp_seq=2 ttl=52 time=38.667 ms
>>> ^C
>>> --- ftp.rrze.uni-erlangen.de <http://ftp.rrze.uni-erlangen.de/> ping 
>>> statistics ---
>>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>>> round-trip min/avg/max/stddev = 32.265/36.540/38.689/3.023 ms
>>> 
>>> Xcode Version 11.2.1 (11B500) and command line tools are installed.  Port 
>>> version is 2.6.2.  Any suggestion is welcome!
>>> 
>>> Thanks,
>>> 
>>> Tarik
>> 
>> --
>> Pierre Malard
>> 
>>   « Les utopies ne sont souvent que des vérités prématurées »
>>   Alphonse de 
>> Lamartine
>>|\  _,,,---,,_
>>/,`.-'`'-.  ;-;;,_
>>   |,4-  ) )-,_. ,\ (  `'-'
>>  '---''(_/--'  `-'\_)   πr
>> 
>> perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. 
>> ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\

Re: Catalina installation problems

[Tarik Cicic]

Hi Pierre,

normal rsync works fine “by hand” tested toward another server.   I have no 
proxy configured, and my “/opt/local/etc/macports/macports.conf” is unmodified.

Could it be that the file rsync.macports.org/macports/release/tarballs/base.tar 
redirects to (in Erlangen?) simply is not there?  Do people normally use 
preinstalled rsync on Mac, or some more recent package? 

Thanks,

Tarik

> On 26 Nov 2019, at 11:29, Pierre Malard  wrote:
> 
> Hi,
> 
> Did you try the rsync command « by hand » on a terminal session?
> An other way: is it a proxy between your PC and MacPorts? Global or specific 
> to MacPorts (file « /opt/local/etc/macports/macports.conf » and « proxy » 
> key)?
> 
>> Le 26 nov. 2019 à 11:20, Tarik Cicic > <mailto:tarik.ci...@gmail.com>> a écrit :
>> 
>> Hi,
>> 
>> I have been using Macports for years, and for first time have problems 
>> installing, after upgrade to MacOS 10.15 Catalina. 
>> 
>> Gray-MBP:~ tarik$ sudo port -d selfupdate
>> Password:
>> DEBUG: Copying /Users/tarik/Library/Preferences/com.apple.dt.Xcode.plist to 
>> /opt/local/var/macports/home/Library/Preferences
>> DEBUG: MacPorts sources location: 
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs 
>> <http://rsync.macports.org/macports/release/tarballs>
>> --->  Updating MacPorts base sources using rsync
>> DEBUG: system: /usr/bin/rsync -rtzvl --delete-after 
>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>  
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs 
>> <http://rsync.macports.org/macports/release/tarballs>
>> rsync: failed to connect to rsync.macports.org <http://rsync.macports.org/>: 
>> Operation timed out (60)
>> rsync error: error in socket IO (code 10) at 
>> /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54/rsync/clientserver.c(106)
>>  [receiver=2.6.9]
>> Command failed: /usr/bin/rsync -rtzvl --delete-after 
>> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>>  
>> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs 
>> <http://rsync.macports.org/macports/release/tarballs>
>> Exit code: 10
>> Gray-MBP:~ tarik$ 
>> 
>> The site is available:
>> 
>> Gray-MBP:~ tarik$ ping rsync.macports.org <http://rsync.macports.org/>
>> PING ftp.rrze.uni-erlangen.de <http://ftp.rrze.uni-erlangen.de/> 
>> (131.188.12.211): 56 data bytes
>> 64 bytes from 131.188.12.211: icmp_seq=0 ttl=52 time=38.689 ms
>> 64 bytes from 131.188.12.211: icmp_seq=1 ttl=52 time=32.265 ms
>> 64 bytes from 131.188.12.211: icmp_seq=2 ttl=52 time=38.667 ms
>> ^C
>> --- ftp.rrze.uni-erlangen.de <http://ftp.rrze.uni-erlangen.de/> ping 
>> statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 32.265/36.540/38.689/3.023 ms
>> 
>> Xcode Version 11.2.1 (11B500) and command line tools are installed.  Port 
>> version is 2.6.2.  Any suggestion is welcome!
>> 
>> Thanks,
>> 
>>  Tarik
> 
> -- 
> Pierre Malard
> 
>   « Les utopies ne sont souvent que des vérités prématurées »
>   Alphonse de 
> Lamartine
>|\  _,,,---,,_
>/,`.-'`'-.  ;-;;,_
>   |,4-  ) )-,_. ,\ (  `'-'
>  '---''(_/--'  `-'\_)   πr
> 
> perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. 
> ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
> 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
> - --> Ce message n’engage que son auteur <--
> 

Re: Catalina installation problems

[Pierre Malard]

Hi,

Did you try the rsync command « by hand » on a terminal session?
An other way: is it a proxy between your PC and MacPorts? Global or specific to 
MacPorts (file « /opt/local/etc/macports/macports.conf » and « proxy » key)?

> Le 26 nov. 2019 à 11:20, Tarik Cicic  a écrit :
> 
> Hi,
> 
> I have been using Macports for years, and for first time have problems 
> installing, after upgrade to MacOS 10.15 Catalina.
> 
> Gray-MBP:~ tarik$ sudo port -d selfupdate
> Password:
> DEBUG: Copying /Users/tarik/Library/Preferences/com.apple.dt.Xcode.plist to 
> /opt/local/var/macports/home/Library/Preferences
> DEBUG: MacPorts sources location: 
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs 
> <http://rsync.macports.org/macports/release/tarballs>
> --->  Updating MacPorts base sources using rsync
> DEBUG: system: /usr/bin/rsync -rtzvl --delete-after 
> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>  
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs 
> <http://rsync.macports.org/macports/release/tarballs>
> rsync: failed to connect to rsync.macports.org <http://rsync.macports.org/>: 
> Operation timed out (60)
> rsync error: error in socket IO (code 10) at 
> /BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54/rsync/clientserver.c(106)
>  [receiver=2.6.9]
> Command failed: /usr/bin/rsync -rtzvl --delete-after 
> rsync://rsync.macports.org/macports/release/tarballs/base.tar 
>  
> /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs 
> <http://rsync.macports.org/macports/release/tarballs>
> Exit code: 10
> Gray-MBP:~ tarik$
> 
> The site is available:
> 
> Gray-MBP:~ tarik$ ping rsync.macports.org <http://rsync.macports.org/>
> PING ftp.rrze.uni-erlangen.de <http://ftp.rrze.uni-erlangen.de/> 
> (131.188.12.211): 56 data bytes
> 64 bytes from 131.188.12.211: icmp_seq=0 ttl=52 time=38.689 ms
> 64 bytes from 131.188.12.211: icmp_seq=1 ttl=52 time=32.265 ms
> 64 bytes from 131.188.12.211: icmp_seq=2 ttl=52 time=38.667 ms
> ^C
> --- ftp.rrze.uni-erlangen.de <http://ftp.rrze.uni-erlangen.de/> ping 
> statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 32.265/36.540/38.689/3.023 ms
> 
> Xcode Version 11.2.1 (11B500) and command line tools are installed.  Port 
> version is 2.6.2.  Any suggestion is welcome!
> 
> Thanks,
> 
>   Tarik

--
Pierre Malard

  « Les utopies ne sont souvent que des vérités prématurées »
  Alphonse de Lamartine
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Catalina installation problems

[Tarik Cicic]

Hi,

I have been using Macports for years, and for first time have problems 
installing, after upgrade to MacOS 10.15 Catalina. 

Gray-MBP:~ tarik$ sudo port -d selfupdate
Password:
DEBUG: Copying /Users/tarik/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: MacPorts sources location: 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
--->  Updating MacPorts base sources using rsync
DEBUG: system: /usr/bin/rsync -rtzvl --delete-after 
rsync://rsync.macports.org/macports/release/tarballs/base.tar 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
rsync: failed to connect to rsync.macports.org: Operation timed out (60)
rsync error: error in socket IO (code 10) at 
/BuildRoot/Library/Caches/com.apple.xbs/Sources/rsync/rsync-54/rsync/clientserver.c(106)
 [receiver=2.6.9]
Command failed: /usr/bin/rsync -rtzvl --delete-after 
rsync://rsync.macports.org/macports/release/tarballs/base.tar 
/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs
Exit code: 10
Gray-MBP:~ tarik$ 

The site is available:

Gray-MBP:~ tarik$ ping rsync.macports.org
PING ftp.rrze.uni-erlangen.de (131.188.12.211): 56 data bytes
64 bytes from 131.188.12.211: icmp_seq=0 ttl=52 time=38.689 ms
64 bytes from 131.188.12.211: icmp_seq=1 ttl=52 time=32.265 ms
64 bytes from 131.188.12.211: icmp_seq=2 ttl=52 time=38.667 ms
^C
--- ftp.rrze.uni-erlangen.de ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.265/36.540/38.689/3.023 ms

Xcode Version 11.2.1 (11B500) and command line tools are installed.  Port 
version is 2.6.2.  Any suggestion is welcome!

Thanks,

Tarik

freeciv SDL - blank screen on Mojave/Catalina

[Dennis van der Burg via macports-users]

Since upgrading to Mojave, when doing a fresh MacPorts install and then 
installing freeciv (SDL client) and clicking on the Apps>MacPorts>Freeciv icon, 
only a blank screen opens instead of a screen with the game running in it.

Has anyone else seen this too? Any ideas how to solve this? This package is 
currently listed on the MacPorts website as having no maintainer.

Kind regards,
Dennis

Re: Catalina ante portas - wine, wine-bottler LTSpice

[Ryan Schmidt]

On Oct 22, 2019, at 10:30, Christoph Kukulies wrote:

> My macOS wants to update (Mojave->Catalina 10.15).
> 
> I’ve heard wine emulator based programs will cease working.
> 
> Has anyone heard there will be an escape for this situation?

This is the latest information I have:

https://lists.macports.org/pipermail/macports-users/2019-October/047502.html

Re: Catalina ante portas - wine, wine-bottler LTSpice

[Pierre Malard]

Stay in 10.14 actually.
The update message of OSX is just an incitation not an obligation. And all 
10.14 update are stil here, just under Catalina suggest.

> Le 22 oct. 2019 à 17:30, Christoph Kukulies  a écrit :
> 
> My macOS wants to update (Mojave->Catalina 10.15).
> 
> I’ve heard wine emulator based programs will cease working.
> 
> Has anyone heard there will be an escape for this situation?
> 
> Best regards,
> 
> Christoph Kukulies
> 

--
Pierre Malard

   « La liberté de la presse ne s'use que lorsqu'on ne s'en sert pas ! »
  Slogan du "Canard enchaîné"
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Catalina ante portas - wine, wine-bottler LTSpice

[Christoph Kukulies]

My macOS wants to update (Mojave->Catalina 10.15).

I’ve heard wine emulator based programs will cease working.

Has anyone heard there will be an escape for this situation?

Best regards,

Christoph Kukulies

Re: mpv, ffmpeg seg fault in macOS catalina

[Michael Newman via macports-users]

Thanks. I’ve used the migration process many times in the past, so no worries.

I appreciate your taking the time to reply.

> On Oct 19, 2019, at 10:08, Chris Jones  wrote:
> 
>> If I upgrade to Catalina (I already have Xcode 11.1) and install MacPorts 
>> for Catalina will ffmpeg stop working?
> 
> As long as you follow the migration guide correctly, no.
> 
> https://trac.macports.org/wiki/Migration 
> <https://trac.macports.org/wiki/Migration>
> 

Re: mpv, ffmpeg seg fault in macOS catalina

[Chris Jones]

> On 18 Oct 2019, at 11:30 pm, Michael Newman via macports-users 
>  wrote:
> 
> I’m sorry, but I don’t understand most of what was written in this thread, 
> but I do have a simple question:
> 
> If I upgrade to Catalina (I already have Xcode 11.1) and install MacPorts for 
> Catalina will ffmpeg stop working?

As long as you follow the migration guide correctly, no.

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

> 
>> On Oct 18, 2019, at 19:00, Gill Bates  wrote:
>> 
>> I recently updated to catalina (10.15) and Xcode (11.1), installed MacPorts 
>> from source (2.6.1) and had it build mpv and its dependencies. However, mpv 
>> (and ffmpeg for example) do not run
> 

Re: mpv, ffmpeg seg fault in macOS catalina

[Michael Newman via macports-users]

I’m sorry, but I don’t understand most of what was written in this thread, but 
I do have a simple question:

If I upgrade to Catalina (I already have Xcode 11.1) and install MacPorts for 
Catalina will ffmpeg stop working?

> On Oct 18, 2019, at 19:00, Gill Bates  <mailto:smo...@shaw.ca>> wrote:
> 
> I recently updated to catalina (10.15) and Xcode (11.1), installed MacPorts 
> from source (2.6.1) and had it build mpv and its dependencies. However, mpv 
> (and ffmpeg for example) do not run

Re: mpv, ffmpeg seg fault in macOS catalina

[Gill Bates]

Thanks all for the explanations and workaround. 


From: "Mojca Miklavec"  
To: "smogus"  
Cc: "macports-users"  
Sent: Friday, October 18, 2019 5:02:55 AM 
Subject: Re: mpv, ffmpeg seg fault in macOS catalina 



V čet., 17. okt. 2019 22:58 je oseba Gill Bates < [ mailto:smo...@shaw.ca | 
smo...@shaw.ca ] > napisala: 



I recently updated to catalina (10.15) and Xcode (11.1), installed MacPorts 
from source (2.6.1) and had it build mpv and its dependencies. However, mpv 
(and ffmpeg for example) do not run apparently related to some new default 
compiler option enforcing 16 byte stack alignment? See: 
[ https://trac.ffmpeg.org/ticket/8073 | https://trac.ffmpeg.org/ticket/8073 ] 
[ https://github.com/mpv-player/mpv/issues/7053 | 
https://github.com/mpv-player/mpv/issues/7053 ] 
[ https://forums.developer.apple.com/thread/121887 | 
https://forums.developer.apple.com/thread/121887 ] 



I first saw [ https://github.com/LuaJIT/LuaJIT/issues/518 | 
https://github.com/LuaJIT/LuaJIT/issues/518 ] , but that one eventually leads 
to the same thread linked above. 


BQ_BEGIN

The advice seems to be to revert Xcode but will rebuilding everything with 
Xcode 10.3 on macos 10.15 really be a workaround? Or is a better choice to 
modify portfiles to include the CFLAG option to disable stack checks as 
mentioned in the linked posts and use Xcode 11.1? 

BQ_END

Workaround is to either blacklist the compiler which has this option turned on 
by default (which is what Chris replied) or in fact use a flag to disable this. 
But disabling this flag is not needed for non-broken compilers, so it's 
probably better to just blacklist the compiler, and the latest compiler with be 
automatically used again when the bug gets fixed. 


BQ_BEGIN

"Part B" is a question for my understanding, is this a really an Xcode/compiler 
issue or a problem with the source software packages? 

BQ_END

I would say that this is in fact an issue with the compiler. As they said, the 
bug has been present before, it's just that nobody noticed it until it was 
switched on by default. I've seen an email saying that this is likely to be 
fixed in one of the next Xcode updates, so it's just a matter of time. 

I believe this affects only source code which uses some heavy optimisations, 
which is why you would not see it in most of the software where high 
performance is not crucially important for the functionality. 

Mojca 

Re: mpv, ffmpeg seg fault in macOS catalina

[Chris Jones]

Hi,

Workaround is to either blacklist the compiler which has this option 
turned on by default (which is what Chris replied) or in fact use a flag 
to disable this. But disabling this flag is not needed for non-broken 
compilers, so it's probably better to just blacklist the compiler, and 
the latest compiler with be automatically used again when the bug gets 
fixed.


Currently I black list {clang > 1099}, so anything in current and future 
Xcode 11 versions. The (insider) claim was Xcode 11.2 'should' address 
this, but last I heard 11.2 beta 2 still had the problem, so time will tell.


Once the fixed clang version is known, the above blacklists can then be 
adjusted to make them non-open ended, but we need to know the fixed 
version first...


Chris

Re: mpv, ffmpeg seg fault in macOS catalina

[Mojca Miklavec]

V čet., 17. okt. 2019 22:58 je oseba Gill Bates  napisala:

> I recently updated to catalina (10.15) and Xcode (11.1), installed
> MacPorts from source (2.6.1) and had it build mpv and its dependencies.
> However, mpv (and ffmpeg for example) do not run apparently related to some
> new default compiler option enforcing 16 byte stack alignment? See:
> https://trac.ffmpeg.org/ticket/8073
> https://github.com/mpv-player/mpv/issues/7053
> https://forums.developer.apple.com/thread/121887
>

I first saw https://github.com/LuaJIT/LuaJIT/issues/518, but that one
eventually leads to the same thread linked above.

 The advice seems to be to revert Xcode but will rebuilding everything with
> Xcode 10.3 on macos 10.15 really be a workaround? Or is a better choice to
> modify portfiles to include the CFLAG option to disable stack checks as
> mentioned in the linked posts and use Xcode 11.1?
>

Workaround is to either blacklist the compiler which has this option turned
on by default (which is what Chris replied) or in fact use a flag to
disable this. But disabling this flag is not needed for non-broken
compilers, so it's probably better to just blacklist the compiler, and the
latest compiler with be automatically used again when the bug gets fixed.

"Part B" is a question for my understanding, is this a really an
> Xcode/compiler issue or a problem with the source software packages?
>

I would say that this is in fact an issue with the compiler. As they said,
the bug has been present before, it's just that nobody noticed it until it
was switched on by default. I've seen an email saying that this is likely
to be fixed in one of the next Xcode updates, so it's just a matter of time.

I believe this affects only source code which uses some heavy
optimisations, which is why you would not see it in most of the software
where high performance is not crucially important for the functionality.

Mojca

Re: mpv, ffmpeg seg fault in macOS catalina

[Christopher Jones]

Hi,

10.15 issues are worked around in

https://github.com/macports/macports-ports/commit/36c3a9a2844ab979be1388280922b25d1f7b56ce
 
<https://github.com/macports/macports-ports/commit/36c3a9a2844ab979be1388280922b25d1f7b56ce>

https://github.com/macports/macports-ports/commit/2de6959b098cb95883863a2cf46575dfcf4c211c
 
<https://github.com/macports/macports-ports/commit/2de6959b098cb95883863a2cf46575dfcf4c211c>

They blacklist Xcode 11 clang, and thus the builds fallback to one of MacPorts 
MP’s clang compilers (9.0). 

Running Xcode 10 on macOS10.15 is unnecessary, and not really a good idea.

For ‘Part B’ difficult to say as long as Xcode has issues (which I understand 
as off 11.1 it does). Until those are addressed hard to say if the project 
themselves also have issues to address.

Chris

> On 17 Oct 2019, at 9:58 pm, Gill Bates  wrote:
> 
> I recently updated to catalina (10.15) and Xcode (11.1), installed MacPorts 
> from source (2.6.1) and had it build mpv and its dependencies. However, mpv 
> (and ffmpeg for example) do not run apparently related to some new default 
> compiler option enforcing 16 byte stack alignment? See:
> https://trac.ffmpeg.org/ticket/8073 <https://trac.ffmpeg.org/ticket/8073>
> https://github.com/mpv-player/mpv/issues/7053 
> <https://github.com/mpv-player/mpv/issues/7053>
> https://forums.developer.apple.com/thread/121887 
> <https://forums.developer.apple.com/thread/121887>
> 
> The advice seems to be to revert Xcode but will rebuilding everything with 
> Xcode 10.3 on macos 10.15 really be a workaround? Or is a better choice to 
> modify portfiles to include the CFLAG option to disable stack checks as 
> mentioned in the linked posts and use Xcode 11.1?
> 
> "Part B" is a question for my understanding, is this a really an 
> Xcode/compiler issue or a problem with the source software packages?
> 
> Thanks in advance for any advice.



smime.p7s
Description: S/MIME cryptographic signature

mpv, ffmpeg seg fault in macOS catalina

[Gill Bates]

I recently updated to catalina (10.15) and Xcode (11.1), installed MacPorts 
from source (2.6.1) and had it build mpv and its dependencies. However, mpv 
(and ffmpeg for example) do not run apparently related to some new default 
compiler option enforcing 16 byte stack alignment? See: 
[ https://trac.ffmpeg.org/ticket/8073 | https://trac.ffmpeg.org/ticket/8073 ] 
[ https://github.com/mpv-player/mpv/issues/7053 | 
https://github.com/mpv-player/mpv/issues/7053 ] 
[ https://forums.developer.apple.com/thread/121887 | 
https://forums.developer.apple.com/thread/121887 ] 

The advice seems to be to revert Xcode but will rebuilding everything with 
Xcode 10.3 on macos 10.15 really be a workaround? Or is a better choice to 
modify portfiles to include the CFLAG option to disable stack checks as 
mentioned in the linked posts and use Xcode 11.1? 

"Part B" is a question for my understanding, is this a really an Xcode/compiler 
issue or a problem with the source software packages? 

Thanks in advance for any advice. 

PortAuthority, MacPorts GUI for Catalina

[Kevin Walzer]

I'd like to take a moment to re-introduce my GUI for MacPorts, 
PortAuthority, now updated for Catalina.


PortAuthority makes it easy to install thousands of Unix software 
packages for macOS.  PortAuthority's familiar three-pane interface lets 
you get started doing what you want to do--finding, installing, and 
removing software for MacPorts.


PortAuthority is the longest-running GUI for MacPorts, in active 
development since the early days of the project (2004, when it was still 
DarwinPorts!), and the only current, stable GUI available on the market. 
Other attempts to develop a native UI for MacPorts have stalled out, but 
PortAuthority is still here, keeping up with changes in both macOS and 
in MacPorts.


My app had previously been proprietary shareware, then was open-sourced 
under the MIT license and costing a nominal sum to register. I have now 
made the app fully free to download and use, but I do request that you 
donate to support the app's development at Liberapay, which is a sort of 
Patreon for OSS developers.


More information about the app, a download link, and a donation link are 
found at https://www.codebykevin.com/portauthority.html.


Thank you!

--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

Re: Xfce4 Won't Launch in macOS Catalina

[Emily Jackson]

> On Oct 12, 2019, at 10:30 PM, Chris Jones  wrote:
> 
> Most likely some command that previously worked is now failing to run, and 
> you need to first figure out what that is. Are there any crash reports, in 
> Console, that might help ? Have you checked to see if its any of the specific 
> possible causes mentioned in those pop ups ?

I uninstalled and reinstalled dbus and ran "sudo port load dbus”; that fixed 
the problem.

Thanks,

Emily

Re: Xfce4 Won't Launch in macOS Catalina

[Chris Jones]

Hi,

I am not sure you have provided enough information for anyone to really be able 
to help.

Most likely some command that previously worked is now failing to run, and you 
need to first figure out what that is. Are there any crash reports, in Console, 
that might help ? Have you checked to see if its any of the specific possible 
causes mentioned in those pop ups ?

Cheers Chris

>> On 13 Oct 2019, at 1:39 am, Emily Jackson  wrote:
> I recently upgraded from Mojave to Catalina and redid my MacPorts 
> installation. I used Xfce4 as a WM under Mojave, but now I can’t get it to 
> launch while running Catalina. I have attached screen shots of the errors I 
> get. I can use quartz-wm with X11, but I would like to get Xfce4 working.
> 
> Thanks,
> 
> Emily
> 
> 

Xfce4 Won't Launch in macOS Catalina

[Emily Jackson]

I recently upgraded from Mojave to Catalina and redid my MacPorts installation. 
I used Xfce4 as a WM under Mojave, but now I can’t get it to launch while 
running Catalina. I have attached screen shots of the errors I get. I can use 
quartz-wm with X11, but I would like to get Xfce4 working.

Thanks,

Emily

Re: The state of Catalina...

[Ryan Schmidt]

On Oct 10, 2019, at 18:05, Carlo Tambuatco wrote:

> After some difficulties caused by upgrading to XCode 11, I'm sure a lot of 
> people are weary of upgrading to Catalina just yet, so could someone give a 
> timeframe for when it should be >95% safe for most macports users to upgrade 
> to Catalina trouble free?

Most of the difficulties of using Xcode 11 on Mojave relate to the fact that 
Xcode 11 does not contain the Mojave SDK. Xcode 11 contains the Catalina SDK. 
As such, the same problems would not affect you if you're using Xcode 11 on 
Catalina.

Since Catalina has just been released and many port maintainers probably 
haven't updated yet, it will probably be months before we've all had a chance 
try to discover whatever problems might exist and to try to fix them. If you'd 
like to participate in that, please do and file tickets or pull requests if you 
discover problems. If you'd rather have an experience closer to things just 
working, then wait a few months before upgrading.