Re: Corrupted ports.tar file?

[Dave Horsfall]

On Tue, 12 Apr 2022, Ryan Schmidt wrote:

> > I did run that first; apologies for not mentioning it (there were no 
> > issues).
> 
> I think you did mention it. I was suggesting you run it again, in case 
> somehow the server files were in a weird state the last time you 
> selfupdated. There was some intermittent network problem affecting the 
> server that generates the ports.tar file a few days ago, and again 
> today; although I thought our rsync updates happened pretty much 
> atomically, maybe it was possible for a set of files to be published 
> briefly that was not correct.

Sorry; my mistake.  I ran it again, and no problems; boy, do I hate these 
heisenbugs :-(

Many thanks.

-- Dave

Re: Corrupted ports.tar file?

[Ryan Schmidt]

On Apr 11, 2022, at 17:02, Dave Horsfall wrote:

> On Mon, 11 Apr 2022, Ryan Schmidt wrote:
> 
>> Run "sudo port selfupdate" to get the most recent ports.tar. Do you 
>> still see the problem then?
> 
> I did run that first; apologies for not mentioning it (there were no 
> issues).

I think you did mention it. I was suggesting you run it again, in case somehow 
the server files were in a weird state the last time you selfupdated. There was 
some intermittent network problem affecting the server that generates the 
ports.tar file a few days ago, and again today; although I thought our rsync 
updates happened pretty much atomically, maybe it was possible for a set of 
files to be published briefly that was not correct.

Re: During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?

[Ryan Schmidt]

On Apr 11, 2022, at 21:10, Jim DeLaHunt wrote:

> Might the presence of "archs='x86_64'" cause the restore_ports.tcl script to 
> ask for +universal variants on the new computer?  
> 
> Should I perhaps null out the value "x86_64" from the archs entries in my 
> installed ports list?  i.e. turn them into "archs='' "? Or should I replace 
> them with the value "arm64"?
> 
> I don't see any mention in the Migration instructions about modifying "archs" 
> entries when migrating from one architecture to another.

No, there is certainly no need to do that. The purpose of the migration process 
is to assist you in moving a MacPorts installation from one computer to another 
where those computer differ by OS version and/or architecture.

MacPorts is probably installing tiff universal because something you wanted to 
install cannot be compiled for arm64, so MacPorts will compile it for x86_64, 
and its dependencies must therefore be installed universal, and one if its 
dependencies is tiff.

Re: curl and openSSL

[James Secan]

It’s a US Gov’t site (NASA): cddis.nasa.gov.  I’m accessing data on their Space 
Geodesy Data archive, pulling files from directory archive/gnss/products/ionex. 
 I filed an initial complaint with them yesterday before I knew in detail what 
was going on and had a response asking for more info this morning.  I’ve sent 
them everything I know, but have heard nothing back.  That was just this 
morning, so it’s too soon to be getting antsy about a response from them.

Jim
> On Apr 12, 2022, at 1:19 PM, Clemens Lang  wrote:
> 
> Hi,
> 
> On Tue, Apr 12, 2022 at 09:17:03AM -0700, James Secan wrote:
>> I switched from using the macOS-supplied curl to MacPorts curl
>> recently, and one of my download scripts which uses curl immediately
>> stopped working.  The error message from curl was:
>> 
>> curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation
>> disabled
>> 
>> From some googling it sounds like this is a problem on the server end
>> and not on my end.  Am I reading this right (I am NOT any kind of
>> expert on SSL)?
> 
> Yes, mostly. Unsafe legacy renegotiation is a mechanism that is
> vulnerable to man in the middle attacks. Can you share which server your
> script was talking to, so I could take a closer look?
> 
> 
>> I’ve switched back to the macOS version of curl for now, but I may try
>> downloading a MacPorts version of curl that doesn’t use openSSL as
>> suggested in a StackExchange post I found.
> 
> This is a message caused by OpenSSL 3.x, so not using OpenSSL will "fix"
> the issue, but leave you vulnerably to the man-in-the-middle vulnerable
> renegotiation.
> 
> -- 
> Clemens

Re: curl and openSSL

[Clemens Lang]

Hi,

On Tue, Apr 12, 2022 at 09:17:03AM -0700, James Secan wrote:
> I switched from using the macOS-supplied curl to MacPorts curl
> recently, and one of my download scripts which uses curl immediately
> stopped working.  The error message from curl was:
> 
> curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation
> disabled
> 
> From some googling it sounds like this is a problem on the server end
> and not on my end.  Am I reading this right (I am NOT any kind of
> expert on SSL)?

Yes, mostly. Unsafe legacy renegotiation is a mechanism that is
vulnerable to man in the middle attacks. Can you share which server your
script was talking to, so I could take a closer look?


> I’ve switched back to the macOS version of curl for now, but I may try
> downloading a MacPorts version of curl that doesn’t use openSSL as
> suggested in a StackExchange post I found.

This is a message caused by OpenSSL 3.x, so not using OpenSSL will "fix"
the issue, but leave you vulnerably to the man-in-the-middle vulnerable
renegotiation.

-- 
Clemens

curl and openSSL

[James Secan]

I switched from using the macOS-supplied curl to MacPorts curl recently, and 
one of my download scripts which uses curl immediately stopped working.  The 
error message from curl was:

curl: (35) error:0A000152:SSL routines::unsafe legacy renegotiation disabled

From some googling it sounds like this is a problem on the server end and not 
on my end.  Am I reading this right (I am NOT any kind of expert on SSL)?

I’ve switched back to the macOS version of curl for now, but I may try 
downloading a MacPorts version of curl that doesn’t use openSSL as suggested in 
a StackExchange post I found.

Jim
Seattle, WA

Re: qt4-mac on M1

[Peter West]

I tried the latest build again. Although there are some things that it baulks 
at, it seems to be doing the main things that I require – essentially, keeping 
track of crypto purchases.

I’ll hope for the best and press on.

Thanks.

—
Peter West
p...@ehealth.id.au
…the whole multitude of his disciples began to rejoice and praise God with a 
loud voice for all the mighty works that they had seen, saying, “Blessed is the 
King who comes in the name of the Lord! Peace in heaven and glory in the 
highest!”

> On 2 Apr 2022, at 12:56 am, Peter West  wrote:
> 
> From that site, I get to the daily builds of origin/master. I can’t see a 
> stable build. The latest build is 
> origin/master: Build #1341 of Revision 
> c0ca54a38f8a0f363ea8a2136be7bdf173114db1 (origin/master)
> 
> 
> I tried this build, and it is unusable, at least on M1.
> 
> Is a stable 5.1.2 dmg available anywhere, to your knowledge?
> 
> 
> —
> Peter West
> p...@ehealth.id.au 
> “Truly, truly, I say to you, an hour is coming, and is now here, when the 
> dead will hear the voice of the Son of God, and those who hear will live.”
> 
>> On 2 Apr 2022, at 12:43 am, Stanton Sanderson > > wrote:
>> 
>> 
>> 
>>> On Apr 1, 2022, at 4:32 AM, Peter West >> > wrote:
>>> 
>>> My Xcode version is 13.3. #61789 was closed as fixed 8 months ago.
>>> 
 On 1 Apr 2022, at 7:22 pm, Peter West >>> > wrote:
 
 I just tried to install kmymoney4 on my M1 running 12.2.1. MacPorts spat 
 the dummy with
 
 Error: Cannot install kmymoney4 for the arch 'arm64' because
 Error: its dependency qt4-mac only supports the archs 'ppc ppc64 i386 
 x86_64’.
 
 
 Is it possible for me to install this somehow?
 
 Should I file a ticket for this?
 
>> 
>> I am a long-time user of KMM, initially through MacPorts. I should emphasize 
>> that I do not have an arm86 machine. Some time ago I visited the kmymoney 
>> website and discovered that the latest version (precompiled for Mac OS) was 
>> easily available, so I downloaded it. I tested KMM 5 on a backup of my KMM 4 
>> file and found no errors. I have been running KMM 5 since. The current 
>> stable version is KMM_5.1.2.
>> 
>> My suggestion would be to download it > > and 1) see if it runs 2) test it with 
>> a copy of your data file. 
>> 
>> Stan
> 

Re: During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?

[Chris Jones]

Hi,

Speaking only for myself, I generally suggest *not* using the 
restore_ports.tcl script. When I migrate to a new OS I generate the list 
of installed ports *and* requested ones, and follow the instructions as 
far as wi[ping out my old ports prior to the update.


However, when restoring the ports I prefer to just manually do this. If 
you just open up the list of requested ports, in whatever text reader 
you prefer, its usually a quite short list (much shorter than all 
installed) and its a short job to go through and reinstall by hand 
whatever you still want. When you do this it will not try and preserve 
the same variants as before, unless you actively request them, and I 
find this a good idea as default variant sometimes get updated so just 
using the same as before is not always the best idea.


This is not to say you still will not have issues with the new Arm arch, 
as for sure some ports will have issues with that. But at least you will 
not have issues because of old settings that should no longer be preserved.


Chris

On 12/04/2022 3:10 am, Jim DeLaHunt wrote:

Hello, MacPorts folks:

I am following the MacPorts wiki "Migration"[1] instructions as I move 
from a macOS 10.14.6 Mojave machine with an intel CPU to a macOS 13.1 
Monterey machine with an arm64 CPU. I got stuck with a bug in the tiff 
port, which fails during destroot under the +universal variant. I opened 
a ticket[2] against tiff +universal on arm64, but that is not my 
question here.


I don't know why MacPorts was trying to install tiff with the +universal 
variant. I am following the Migration instructions. They have me make a 
list of installed ports using `port -qv installed`. None of these 
entries mention "requested_variants='+universal'". 91% have an empty 
string for requested variants. 9% request some other variant. However, 
two-thirds mention "archs='x86_64'", while the other one-third mention 
"archs='noarch'", and none have empty strings or some other value for 
"archs". I use the restore_ports.tcl script to install the ports on the 
new computer.


Here are four representative entries from my list of installed ports:

   aalib @1.4rc5_5 (active) requested_variants='' platform='darwin 18' 
archs='x86_64' date='2021-08-30T13:16:05-0700'
   abcde @2.9.3_1 (active) requested_variants='' platform='darwin 18' 
archs='noarch' date='2022-01-23T21:52:02-0800'
   apr-util @1.6.1_2+no_bdb (active) requested_variants='+no_bdb' 
platform='darwin 18' archs='x86_64' date='2021-08-30T13:16:21-0700'
   aspell @0.60.8_1 (active) requested_variants='-nls' platform='darwin 18' 
archs='x86_64' date='2021-08-30T13:34:34-0700'

Might the presence of "archs='x86_64'" cause the restore_ports.tcl 
script to ask for +universal variants on the new computer?


Should I perhaps null out the value "x86_64" from the archs entries in 
my installed ports list?  i.e. turn them into "archs='' "? Or should I 
replace them with the value "arm64"?


I don't see any mention in the Migration instructions about modifying 
"archs" entries when migrating from one architecture to another.


[1] 
[2] , tiff@4.3.0_0+universal: 
Failed to destroot tiff, "libtiff-4.pc differs"


--
.--Jim DeLaHunt, Vancouver, Canada