Re: Foiled Again

[Michael Newman via macports-users]

Thanks. nbsmtp is now installed.

> On Oct 2, 2024, at 14:04, Ryan Carsten Schmidt  
> wrote:
> 
> On Oct 2, 2024, at 00:13, Ryan Carsten Schmidt wrote:
>> 
>>> On Oct 2, 2024, at 00:06, Michael Newman wrote:
>>> 
>>> I did my best with the bug report.
>> 
>> 
>> Thanks! The ticket URL is https://trac.macports.org/ticket/71012
> 
> nbsmtp should be fixed now. Wait a couple hours for the fix to sync out to 
> the public servers, then you can "sudo port selfupdate" to receive the fix. 
> 
> This has been broken for years and you were the first to report it! Thanks 
> for letting us know so we could fix it. 



smime.p7s
Description: S/MIME cryptographic signature

Re: ffmpeg - Abort trap 6

[Michael Newman via macports-users]

Building from source seems to have worked:

Sellotape:~ mnewman$ port -v installed ffmpeg
The following ports are currently installed:
  ffmpeg @4.4.4_8+gpl2 (active) requested_variants='' platform='darwin 24' 
archs='x86_64' date='2024-10-03T12:05:08+0700’

I will do my best to file a report with Apple.

Thanks for the help.

> On Oct 3, 2024, at 11:14, Ryan Carsten Schmidt  
> wrote:
> 
> On Oct 2, 2024, at 22:28, Michael Newman wrote:
>> 
>> Sellotape:bin mnewman$ file /opt/local/lib/libavcodec.58.dylib 
>> /opt/local/lib/libavcodec.58.134.100.dylib
>> /opt/local/lib/libavcodec.58.dylib: data
>> /opt/local/lib/libavcodec.58.134.100.dylib: data
>> 
>> Unfortunately, I don’t recall if ffmpeg was built from source or via binary. 
>> Sorry.
>> 
>> This on a 2019 Intel iMac upgraded to Sequoia (15.0) just two days ago.
> 
> I can confirm this problem in the ffmpeg archive we produced on our macOS 15 
> x86_64 build machine. 
> 
> Large portions of that dylib file, including the beginning that allow the 
> file command to identify what it is, are null bytes. The file has been 
> corrupted. 
> 
> As far as I know, this is a bug in the APFS filesystem. The problem goes back 
> to macOS 10.15 at least but we only learned about it more recently. 
> 
> Our ticket on this is https://trac.macports.org/ticket/67336. My Apple 
> Feedback report about this is FB12160429. Apple has never acknowledged it or 
> responded to it. Summarizing:
> 
> What happens is that the filesystem keeps track of which regions in a file 
> are nulls ("holes") and represents the file sparsely so that those holes 
> don't actually take up disk space. When we use tar to create an archive of 
> files installed by a port, tar learns from the filesystem about those holes 
> and also represents them sparsely in the archive, excluding those sections of 
> the file from the archive, since they're supposed to be nulls. The bug is 
> that the filesystem tells tar there are holes when in fact those holes had 
> already been filled with data and should not be excluded, but there's no way 
> for tar to know that the filesystem is lying. 
> 
> We have a workaround we can employ for root MacPorts installations (run 
> /usr/sbin/purge before creating the tar archive to clear the filesystem 
> cache) but we haven't implemented it in MacPorts base because we don't know a 
> solution for non-root MacPorts installations. This fix has only been 
> implemented manually in one port (pari). I had thought to write a PortGroup 
> that could be included in affected ports, but there's no reason why only 
> specific ports should be affected. It could affect any port and any file. 
> 
> BSD tar 3.6.0 and later can be told not to represent files sparsely which 
> would work around the bug but even in macOS 15 Apple includes an older 
> version of BSD tar than that. GNU tar can be told whether to represent files 
> sparsely, and doesn't by default, but GNU tar isn't included in any macOS 
> versions that support APFS. 
> 
> I could increase the revision of the ffmpeg port to rebuild it and make a new 
> archive but there is no guarantee that the problem would not strike again, on 
> any of the builders using the APFS filesystem.
> 
> For now, you can rebuild ffmpeg from source and hope that the issue does not 
> occur on your machine:
> 
> sudo port -ns upgrade --force ffmpeg
> 
> Apple pays more attention to issues that affect more users, measured by how 
> many duplicates a bug has. If this problem affects you please file a bug 
> report with Apple and reference my 2023 bug number FB12160429 and the 2019 
> bug FB7378125 that I believe it's a duplicate of so that they can mark your 
> bug as a duplicate and hopefully see how big a problem this is and start 
> working on a fix. 
> 
> https://feedbackassistant.apple.com/
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: ffmpeg - Abort trap 6

[Michael Newman via macports-users]

Sellotape:bin mnewman$ file /opt/local/lib/libavcodec.58.dylib 
/opt/local/lib/libavcodec.58.134.100.dylib
/opt/local/lib/libavcodec.58.dylib: data
/opt/local/lib/libavcodec.58.134.100.dylib: data

Unfortunately, I don’t recall if ffmpeg was built from source or via binary. 
Sorry.

This on a 2019 Intel iMac upgraded to Sequoia (15.0) just two days ago.

> On Oct 3, 2024, at 10:02, Ryan Carsten Schmidt  
> wrote:
>
> On Oct 2, 2024, at 20:50, Michael Newman wrote:
>>
>> Reason: tried: '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file),
>
>> '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file),
>
> That shouldn't be... What kinds of files are these then—what does this 
> command say?
>
> file /opt/local/lib/libavcodec.58.dylib 
> /opt/local/lib/libavcodec.58.134.100.dylib
>
> Do you recall seeing whether this port built from source on your system or if 
> you received a binary? If you're not sure that's ok. I'll check the archives 
> on our server to see if they have this problem. What macOS version and 
> architecture (arm64 or c86_64) is the machine where you see this problem?



smime.p7s
Description: S/MIME cryptographic signature

Re: ffmpeg - Abort trap 6

[Michael Newman via macports-users]

I tried this:

Sellotape:bin mnewman$ sudo port -v rev-upgrade
Password:
--->  Updating database of binaries
--->  Scanning binaries for linking errors
Could not open /opt/local/lib/libavcodec.58.dylib: Not a Mach-O file 
(referenced from /opt/local/bin/ffmpeg)
--->  No broken files found.
--->  No broken ports found.

And selfupdate and upgrade:

The ports tree has been updated.
All installed ports are up to date.
Sellotape:bin mnewman$ sudo port -v upgrade outdated
Nothing to upgrade.
--->  Scanning binaries for linking errors
Could not open /opt/local/lib/libavcodec.58.dylib: Not a Mach-O file 
(referenced from /opt/local/bin/ffmpeg)
--->  No broken files found.
--->  No broken ports found.

Should I remove the port and install again, or what?

> On Oct 3, 2024, at 09:44, Ken Cunningham  
> wrote:
> 
> Not a systemic issue with the software or MacPorts, as with
> 
> % port -v installed ffmpeg
> The following ports are currently installed:
>   ffmpeg @4.4.4_8+gpl2 (active) requested_variants='' platform='darwin 24' 
> archs='arm64' date='2024-09-25T14:50:44-0700'
> 
> I see:
> 
> % ffmpeg -version
> ffmpeg version 4.4.4 Copyright (c) 2000-2023 the FFmpeg developers
> built with Apple clang version 16.0.0 (clang-1600.0.26.3)
> configuration: --prefix=/opt/local --cc=/usr/bin/clang 
> --mandir=/opt/local/share/man --enable-audiotoolbox --disable-indev=jack 
> --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb 
> --disable-libxcb --disable-libxcb-shm --disable-libxcb-xfixes --enable-opencl 
> --disable-outdev=xv --enable-sdl2 --disable-securetransport 
> --enable-videotoolbox --enable-avfilter --enable-avresample 
> --enable-fontconfig --enable-gnutls --enable-libass --enable-libbluray 
> --enable-libdav1d --enable-libfreetype --enable-libfribidi 
> --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus 
> --enable-librsvg --enable-libsoxr --enable-libspeex --enable-libtheora 
> --enable-libvorbis --enable-libvpx --enable-libzimg --enable-libzvbi 
> --enable-lzma --enable-pthreads --enable-shared --enable-swscale 
> --enable-zlib --enable-libaom --enable-libsvtav1 --arch=arm64 --enable-gpl 
> --enable-libvidstab --enable-libx264 --enable-libx265 --enable-libxvid 
> --enable-postproc
> libavutil  56. 70.100 / 56. 70.100
> libavcodec 58.134.100 / 58.134.100
> libavformat58. 76.100 / 58. 76.100
> libavdevice58. 13.100 / 58. 13.100
> libavfilter 7.110.100 /  7.110.100
> libavresample   4.  0.  0 /  4.  0.  0
> libswscale  5.  9.100 /  5.  9.100
> libswresample   3.  9.100 /  3.  9.100
> libpostproc55.  9.100 / 55.  9.100
> 
> 
> 
> you might try doing this:
> 
> sudo port -v rev-upgrade
> 
> and of course, if you have not updated your ports lately, that would be step 
> 1 to consider:
> 
> sudo port seflupdate
> sudo port -v upgrade outdated
> 
> Best,
> 
> Ken
> 
> 
> 
>> On Oct 2, 2024, at 6:49 PM, Michael Newman via macports-users 
>>  wrote:
>> 
>> Sorry to bother everyone again,
>> 
>> I have a shell script that has been working fine for several years which 
>> uses ffmpeg to add audio to a video.
>> 
>> It stopped working after migrating to the latest MacPorts.
>> 
>> I can’t tell you the version of ffmpeg because:
>> 
>> Sellotape:bin mnewman$ ffmpeg -version
>> dyld[10354]: Library not loaded: /opt/local/lib/libavcodec.58.dylib
>>   Referenced from: <248D2E71-7C97-3A27-99F5-2D7EB9E6BCE7> 
>> /opt/local/bin/ffmpeg
>>   Reason: tried: '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), 
>> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.dylib' (no 
>> such file), '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), 
>> '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file), 
>> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.134.100.dylib'
>>  (no such file), '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o 
>> file)
>> Abort trap: 6
>> 
>> A similar error appears when the script tries to run ffmpeg:
>> 
>> Thu Oct  3 06:50:00 +07 2024 YouTube Korat Upload
>> dyld[9528]: Library not loaded: /opt/local/lib/libavcodec.58.dylib
>>   Referenced from: <248D2E71-7C97-3A27-99F5-2D7EB9E6BCE7> 
>> /opt/local/bin/ffmpeg
>>   Reason: tried: '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), 
>> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.dylib' (no 
>> such file), '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), 
>> '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file), 
>> '/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.134.100.dylib'
>>  (no such file), '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o 
>> file)
>> 
>> 
>> I don’t know if this is something to report to the developer or if it is 
>> some sort of error when MacPorts was building the ffmpeg port or if it’s 
>> something I did wrong.
>> 
>> Mike Newman
>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

ffmpeg - Abort trap 6

[Michael Newman via macports-users]

Sorry to bother everyone again,

I have a shell script that has been working fine for several years which uses 
ffmpeg to add audio to a video.

It stopped working after migrating to the latest MacPorts.

I can’t tell you the version of ffmpeg because:

Sellotape:bin mnewman$ ffmpeg -version
dyld[10354]: Library not loaded: /opt/local/lib/libavcodec.58.dylib
  Referenced from: <248D2E71-7C97-3A27-99F5-2D7EB9E6BCE7> /opt/local/bin/ffmpeg
  Reason: tried: '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), 
'/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.dylib' (no 
such file), '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), 
'/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file), 
'/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.134.100.dylib'
 (no such file), '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o 
file)
Abort trap: 6

A similar error appears when the script tries to run ffmpeg:

Thu Oct  3 06:50:00 +07 2024 YouTube Korat Upload
dyld[9528]: Library not loaded: /opt/local/lib/libavcodec.58.dylib
  Referenced from: <248D2E71-7C97-3A27-99F5-2D7EB9E6BCE7> /opt/local/bin/ffmpeg
  Reason: tried: '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), 
'/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.dylib' (no 
such file), '/opt/local/lib/libavcodec.58.dylib' (not a mach-o file), 
'/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o file), 
'/System/Volumes/Preboot/Cryptexes/OS/opt/local/lib/libavcodec.58.134.100.dylib'
 (no such file), '/opt/local/lib/libavcodec.58.134.100.dylib' (not a mach-o 
file)


I don’t know if this is something to report to the developer or if it is some 
sort of error when MacPorts was building the ffmpeg port or if it’s something I 
did wrong.

Mike Newman




smime.p7s
Description: S/MIME cryptographic signature

Re: Foiled Again

[Michael Newman via macports-users]

I did my best with the bug report. I had no idea what to put in the comments 
section.

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

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

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



-- 
https://www.mgnewman.com



> On Oct 2, 2024, at 10:58 AM, Joshua Root  wrote:
> 
> Michael Newman wrote:
> 
>> This morning I upgraded my 2019 iMac to Sequoia and then did a port migrate.
>> 
>> I think everything went OK, except for the following:
>> 
>> The following ports could not be restored:
>>  - nbsmtp
>>Failed: Unable to execute target 'activate' for port nbsmtp - see its 
>> log
>> for details
>> 
>> When I look at what I think is the log, I see this at the end, which means 
>> nothing to me:
>> 
>> :error:build Failed to build nbsmtp: command execution failed
>> :debug:build Error code: CHILDSTATUS 70925 2
>> :debug:build Backtrace: command execution failed
>> :debug:build while executing
>> :debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
>> :debug:build invoked from within
>> :debug:build "command_exec -callback portprogress::target_progress_callback 
>> build"
>> :debug:build (procedure "portbuild::build_main" line 10)
>> :debug:build invoked from within
>> :debug:build "$procedure $targetname"
>> :error:build See 
>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_mail_nbsmtp/nbsmtp/main.log
>>  for details.
> 
> About all that particular part of the log means is "running some shell 
> command failed during the build phase". The relevant error will be earlier. 
> This is part of why we always ask for full logs; end users can't be expected 
> to know which parts of the log are relevant.
> 
>> When I search for a ticket for nbsmtp I find nothing. (But I’m not very good 
>> at searching.)
> 
> The easiest way to check if there are any tickets open against a port is 
> probably to go to its page on ports.macports.org, click "Details", and check 
> the "Trac Tickets" tab. It looks like there are not any open tickets in this 
> case. There's a handy "Report an Issue with this port" link on the same page.
> 
>> What next?
> 
> Open a ticket and add the complete main.log as an attachment.
> 
> - Josh
> 



smime.p7s
Description: S/MIME cryptographic signature

Foiled Again

[Michael Newman via macports-users]

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

I think everything went OK, except for the following:

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

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

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

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

What next?

PS - To be honest, I don’t think I’m actually using nbsmtp anywhere so there’s 
probably nothing to do.

smime.p7s
Description: S/MIME cryptographic signature

Re: Upgrade Dilemma

[Michael Newman via macports-users]

There already is a bug report (#70869). msmtp fails because building gas fails.

> On Sep 30, 2024, at 09:20, Ryan Carsten Schmidt  
> wrote:
>
> On Sep 29, 2024, at 19:25, Michael Newman wrote:
>>
>> I’ve been migrating MacPorts both to new machines and as a result of OS 
>> upgrades for many years now. It has always worked OK.
>>
>> The migration after the Sequoia upgrade on an MBA didn’t go so well; part of 
>> which was my fault. In the end I was able to migrate all ports except for 
>> msmtp.
>>
>> That particular port is not so important on the MBA, but I have a 2019 Intel 
>> iMac on which it gets extensive use.
>>
>> As a result, I can’t really upgrade the old iMac to Sequoia.
>>
>> Am I missing something here or am I stuck?
>
> If a port is not building, file a bug report in the issue tracker.



smime.p7s
Description: S/MIME cryptographic signature

Upgrade Dilemma

[Michael Newman via macports-users]

I’ve been migrating MacPorts both to new machines and as a result of OS 
upgrades for many years now. It has always worked OK.

The migration after the Sequoia upgrade on an MBA didn’t go so well; part of 
which was my fault. In the end I was able to migrate all ports except for msmtp.

That particular port is not so important on the MBA, but I have a 2019 Intel 
iMac on which it gets extensive use.

As a result, I can’t really upgrade the old iMac to Sequoia.

Am I missing something here or am I stuck?

Mike Newman






smime.p7s
Description: S/MIME cryptographic signature

Re: Requested Ports

[Michael Newman via macports-users]

Well, this is embarrassing.

I was surprised that the snapshot list had two items:

Fifteen:desktop mnewman$ port snapshot --list
ID  Created  Note
== 2  2024-09-22 09:34:22  
snapshot created for migration
 1  2024-09-22 00:22:41  snapshot created for migration

I’m usually in bed by 8:30 and asleep by 9:00. There’s little chance that I 
would ever be awake after midnight and even less chance that I would be doing a 
MacOS upgrade and MacPorts migration at that hour.

However, it appears that’s exactly what I did. I have no recollection at all of 
doing this.

In my defense, I had just been home for a few days after a 30+ hour journey 
across ten time zones from Portland, Oregon to our home in Northeast Thailand. 
I was tired, jet-lagged and fighting a nasty cold. I guess anything is possible.

Sorry for wasting everyone’s time. On the plus side, I learned a lot and 
appreciate the help.

Mike

> On Sep 24, 2024, at 10:00, Joshua Root  wrote:
>
> Michael Newman wrote:
>
>> I did what Arno suggested (thank you) and I now have a requested.txt file 
>> that, as far as I can tell, is a good representation of both:
>>
>> • The ports I migrated to this machine when I first set it up last October.
>> • The ports that I later installed.
>>
>> What I still don’t understand is what happened to the ports that I either 
>> migrated or installed?
>>
>> Many of them simply disappeared after I upgraded to Sequoia and used the new 
>> MacPorts migration procedure.
>>
>> Fifteen:desktop mnewman$ xargs -n1 sudo port setrequested < old_requested.txt
>> Password:
>> Error: exiftool is not installed
>> Error: jshon is not installed
>> Error: lynx is not installed
>> Error: mailutils is not installed
>> Error: msmtp is not installed
>> Error: nano is not installed
>> Error: nbsmtp is not installed
>> Error: tree is not installed
>>
>> (old_requested.txt is the file I used to migrate to the new machine and 
>> which I recovered from TimeMachine.)
>>
>> Where did they all go?
>
> I don't know exactly what you did, but assuming you ran 'port migrate' at 
> some point in the process and didn't delete the snapshot afterwards, you can 
> compare the snapshot with your installation's current state by finding the 
> snapshot ID with 'port snapshot --list' and then running 'port snapshot 
> --diff  --all' where  is the appropriate ID number.
>
> Migration will only restore requested ports and their dependencies by default 
> (and there should have been a message telling you about any ports that would 
> not be restored, and a prompt asking if you want to continue), so it's 
> possible you will find that some of the ports you want were not marked as 
> requested when the snapshot was created. If that's the case, you can run 
> 'sudo port restore --last --all' to restore all of the ports in the snapshot 
> including unrequested ones.
>
> - Josh
>



smime.p7s
Description: S/MIME cryptographic signature

Re: Requested Ports

[Michael Newman via macports-users]

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

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

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

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

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

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

Where did they all go?

> On Sep 23, 2024, at 21:33, Arno Hautala  wrote:
>
> I think an easier way to resolve the missed requested items would be with:
>
> xargs -n1 sudo port setrequested < requested.txt
>
> The ‘-n1’ tells xargs to execute the command once for each argument. It will 
> be less efficient because you’re starting up the port command multiple times, 
> but you’ll only be missing the failed ports.
>
> MacPorts doesn’t keep a history of installed ports, so the currently 
> installed / requested is the best you can do at any given time. And your 
> TimeMachine requested.txt is the best you’ll get for the past.
>
> Any manually installed ports should already be marked as requested.
>
>> On Sep 23, 2024, at 06:05, Michael Newman via macports-users 
>>  wrote:
>>
>> After yesterday’s partially unsuccessful migration, I noticed that some 
>> ports that I had previously installed were missing after the migration, even 
>> though there was no error message during “sudo port migrate” on any of the 
>> missing ports. For example, I have several shell scripts that use “sponge” 
>> which is found in moreutils. Those scripts started failing after the 
>> migration yesterday:
>>
>> /Users/mnewman/bin/remove_jpg.sh: line 23: /opt/local/bin/sponge: No such 
>> file or directory
>>
>> I ran this: port echo requested | cut -d ' ' -f 1 | uniq > requested.txt and 
>> found that it only contained the following ports:
>>
>> aom
>> ffmpeg
>> ImageMagick
>>
>> Those are all ports that I installed manually after the migration partially 
>> failed.
>>
>> I used TimeMachine to find the previous requested.txt file and see that it 
>> contains the following:
>>
>> bash
>> curl
>> exiftool
>> ffmpeg
>> ImageMagick
>> jshon
>> lynx
>> mailutils
>> moreutils
>> msmtp
>> nano
>> nbsmtp
>> tree
>>
>> I’ve read this:
>>
>>•
>>• Note: ports that are not available on your new platform will be 
>> skipped, with only a warning message.
>>• Restore requested status: If you saved the list of requested ports, 
>> you can now restore the requested flags for your newly installed ports to 
>> their former states.sudo port unsetrequested installed
>> xargs sudo port setrequested < requested.txt
>>
>> Warning: if a port in requested.txt was not installed in the previous step, 
>> the iterative setrequested will terminate, leaving some ports still marked 
>> as not-requested. Edit requested.txt to remove any ports that were not 
>> installed and repeat this step. Double-check your desired ports are set as 
>> requested with port echo requested.
>> And don’t understand it at all.
>>
>> What do I need to do to get a list of all the ports that I have requested in 
>> the past? Or, is the TimeMachine resurrection the best I can do; even though 
>> I’m sure I’ve installed several ports since the resurrected requested.txt 
>> file was created.
>>
>> Please excuse my ignorance in these matters. I’ve been a MacPorts user for a 
>> long time, but don’t know much about it. I’ve done many migrations both 
>> after OS updates and from machine to machine and have always had success. 
>> This has been a confusing experience.
>>
>> Mike Newman
>> Korat, Thailand
>>
>>
>
> --
> arno  s  hautala/-|   a...@fracas.net
>
> pgp b2c9d448
>
>
>
>



smime.p7s
Description: S/MIME cryptographic signature

Requested Ports

[Michael Newman via macports-users]

After yesterday’s partially unsuccessful migration, I noticed that some ports 
that I had previously installed were missing after the migration, even though 
there was no error message during “sudo port migrate” on any of the missing 
ports. For example, I have several shell scripts that use “sponge” which is 
found in moreutils. Those scripts started failing after the migration yesterday:

/Users/mnewman/bin/remove_jpg.sh: line 23: /opt/local/bin/sponge: No such file 
or directory

I ran this: port echo requested | cut -d ' ' -f 1 | uniq > requested.txt and 
found that it only contained the following ports:

aom
ffmpeg
ImageMagick

Those are all ports that I installed manually after the migration partially 
failed.

I used TimeMachine to find the previous requested.txt file and see that it 
contains the following:

bash
curl
exiftool
ffmpeg
ImageMagick
jshon
lynx
mailutils
moreutils
msmtp
nano
nbsmtp
tree

I’ve read this:

Note: ports that are not available on your new platform will be skipped, with 
only a warning message. 
Restore requested status: If you saved the list of requested ports, you can now 
restore the requested flags for your newly installed ports to their former 
states.
sudo port unsetrequested installed
xargs sudo port setrequested < requested.txt
Warning: if a port in requested.txt was not installed in the previous step, the 
iterative setrequested will terminate, leaving some ports still marked as 
not-requested. Edit requested.txt to remove any ports that were not installed 
and repeat this step. Double-check your desired ports are set as requested with 
port echo requested.
And don’t understand it at all.

What do I need to do to get a list of all the ports that I have requested in 
the past? Or, is the TimeMachine resurrection the best I can do; even though 
I’m sure I’ve installed several ports since the resurrected requested.txt file 
was created.

Please excuse my ignorance in these matters. I’ve been a MacPorts user for a 
long time, but don’t know much about it. I’ve done many migrations both after 
OS updates and from machine to machine and have always had success. This has 
been a confusing experience.

Mike Newman
Korat, Thailand




smime.p7s
Description: S/MIME cryptographic signature

Re: Migration Errors after Sequoia

[Michael Newman via macports-users]

Previously I reported.

> On Sep 22, 2024, at 19:00, macports-users-requ...@lists.macports.org wrote:
> 
> Attempting to migrate following Sequoia installation I got the following:
> 
>Migration finished with errors.
>The following ports could not be restored:
> - ImageMagick
>   Skipped because its dependency aom failed
> - ffmpeg
>   Skipped because its dependency aom failed
> - msmtp
>   Skipped because its dependency gss failed
> - nbsmtp
>   Failed: Unable to execute target 'activate' for port nbsmtp -
>see its log for details
> 
> Error: Failed to build aom: command execution failed

It was suggested that I should delete and reinstall the command line tools to 
get aom to build. I did that and aom now builds and I was able to install 
ImageMagic and ffmpeg. I was also able to install nbsmtp.

However, I still can’t install msmtp because:

Error: Failed to build gss: command execution failed

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

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

Mike Newman
Korat, Thailand



smime.p7s
Description: S/MIME cryptographic signature

Re: Migration Errors after Sequoia

[Michael Newman via macports-users]

I’m sorry, but this is way beyond my ability. I have many questions.

The guide to filing a ticket says "Clean and try again”

• Does “clean” mean I should run "sudo port -f clean --all all”
• Does “try again” mean I should run "sudo port migrate” again, or try to 
install each failed port separately?
• Since three of the failures were based on aom, should I try and install aom 
separately, or what?

I ran clean as described above and got zillions of messages like: "Warning: All 
compilers are either blacklisted or unavailable; defaulting to first fallback 
option”

Note that the command line tools seem to be installed:

Fifteen:~ mnewman$ pkgutil 
--pkg-info=com.apple.pkg.{CLTools_Executables,CLTools_Base,DeveloperToolsCLI,DeveloperToolsCLILeo}
 2>/dev/null | sed -n 's/^version: //p'
16.0.0.0.1.1724870825

As you can probably tell, I am neither knowledgeable nor very smart, so I’ll 
need step-by-step instructions as to what to do.

Sorry,

Mike Newman


> On Sep 22, 2024, at 14:49, Christopher Jones  wrote:
> 
>> 
>> That log file is extremely long; too long to include with this message. But, 
>> there is this:
> 
> you should never send attachments to this list anyway. See below.
> 
>> 
>> :info:build Exit code: 2
>> :error:build Failed to build aom: command execution failed
>> :debug:build Error code: CHILDSTATUS 2671 2
>> :debug:build Backtrace: command execution failed
>> :debug:build while executing
>> :debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
>> :debug:build invoked from within
>> :debug:build "command_exec -callback portprogress::target_progress_callback 
>> build"
>> :debug:build (procedure "portbuild::build_main" line 10)
>> :debug:build invoked from within
>> :debug:build "$procedure $targetname"
>> 
>> I have no idea how to fix any of this. Everything else worked so I’m 
>> assuming that I did the right things with Xcode and the CL Tools.
>> 
>> Detailed instructions appreciated.
> 
> The above its pretty useless to help you, we need the full logs.
> 
> Follow the instructions at
> 
> https://trac.macports.org/wiki/Tickets
> 
> to first check if there is an existing ticket for your issue, and if not file 
> a new one. Upload a complete (compressed) log from a clean build attempt 
> there.
> 
> Chris
> 



smime.p7s
Description: S/MIME cryptographic signature

Migration Errors after Sequoia

[Michael Newman via macports-users]

This on a 15” M2 MBA 16/512

Attempting to migrate following Sequoia installation I got the following:

Migration finished with errors.
The following ports could not be restored:
 - ImageMagick
   Skipped because its dependency aom failed
 - ffmpeg
   Skipped because its dependency aom failed
 - msmtp
   Skipped because its dependency gss failed
 - nbsmtp
   Failed: Unable to execute target 'activate' for port nbsmtp -
see its log for details

Error: Failed to build aom: command execution failed
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/main.log
 for details.

That log file is extremely long; too long to include with this message. But, 
there is this:

:info:build Exit code: 2
:error:build Failed to build aom: command execution failed
:debug:build Error code: CHILDSTATUS 2671 2
:debug:build Backtrace: command execution failed
:debug:build while executing
:debug:build "system {*}$notty {*}$callback {*}$nice $fullcmdstring"
:debug:build invoked from within
:debug:build "command_exec -callback portprogress::target_progress_callback 
build"
:debug:build (procedure "portbuild::build_main" line 10)
:debug:build invoked from within
:debug:build "$procedure $targetname"

I have no idea how to fix any of this. Everything else worked so I’m assuming 
that I did the right things with Xcode and the CL Tools.

Detailed instructions appreciated.

Mike Newman
Korat, Thailand



smime.p7s
Description: S/MIME cryptographic signature

Migrating After Sonoma Install

[Michael Newman via macports-users]

Don’t worry. The migration went fine and, fingers crossed, everything works.

However, it always amazes me how long this takes. I have only 13 ports in 
requested.txt. There are 148 ports in myports.txt. I get this, but I still find 
it amazing.

On a 2019 Intel iMac, the migration started at 11:00AM. When I went to bed at 
9:00PM it was still cranking away. I have no idea how long it actually took. 
But, at least 10 hours. This also amazes me.

On the other hand, my M1 MBA also has 13 in requested.txt and 148 in 
myports.txt. On this machine the post-Sonoma migration took about six hours. 
Still a long time, but somewhat less amazing.

Thanks to everyone who makes all this stuff possible.

Mike Newman
Korat, Thailand

smime.p7s
Description: S/MIME cryptographic signature

Warning: Error parsing file...

[Michael Newman via macports-users]

I recently had to reformat my boot drive, reinstall MacOS and restore from a 
CCC backup. After doing so I ran: 

sudo port -u upgrade outdated

And received many warnings like this:

--->  Scanning binaries for linking errors
Warning: Error parsing file /opt/local/bin/msgcmp: Error opening or reading file
Warning: Error parsing file /opt/local/bin/msgcomm: Error opening or reading 
file


What should I do about this?

Mike Newman
Korat, Thailand

py310-markdown - Failed to fetch signature for archive

[Michael Newman via macports-users]

After: sudo port -u upgrade outdated

Error: Failed to archivefetch py310-markdown: Failed to fetch signature for 
archive: The requested URL returned error: 503

Then:

sudo port install py310-markdown
--->  Computing dependencies for py310-markdown
--->  Fetching archive for py310-markdown
--->  Attempting to fetch py310-markdown-3.3.7_0.darwin_21.noarch.tbz2 from 
https://packages.macports.org/py310-markdown
--->  Attempting to fetch py310-markdown-3.3.7_0.darwin_21.noarch.tbz2.rmd160 
from https://packages.macports.org/py310-markdown
Error: Failed to archivefetch py310-markdown: Failed to fetch signature for 
archive: The requested URL returned error: 503
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_python_py-markdown/py310-markdown/main.log
 for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
Error: Processing of port py310-markdown failed

No idea what to do about this, but the error is preventing other outdated ports 
from upgrading.

Re: A simple request (MkHexGrid) turned into ...

[Michael]

On 2022-05-14, at 1:21 PM, Mojca Miklavec  wrote:

> On Sat, 14 May 2022 at 19:55, Michael wrote:
>> On 2022-05-14, at 9:27 AM, Mojca Miklavec wrote:
>>> On Sat, 14 May 2022 at 16:20, Michael wrote:
>>>> 
>>>> So I thought I'd install a simple little hex map generator. Mkhexgrid.
>>>> 
>>>> Hasn't been updated in years, should be simple, right?
>>> ...
>>> You can check why you are getting weird dependency by running the
>>> following command:
>>>   port rdeps mkhexgrid
>> 
>> Hmm. Just some highlights. It took a compiler??
> 
> In such cases it's crucial to also provide information about the macOS
> version that you are using.

Indeed. 10.9.5. And ...

>
> https://github.com/macports/macports-ports/blob/master/multimedia/dav1d/Portfile#L47-L50
> suggesting that this looks like a workaround for a bug in the meson
> build system that has been ignored for more than a year:
>https://github.com/mesonbuild/meson/issues/8307
> and it looks as if this was only relevant for macOS <= 10.9.

Yea ... lovely :-).

>> Cairo was another port installed, and not on that list. (Checked -- it's 
>> +quartz -X11)
> 
> If you want to know which port requires x11, you can run "port depend
> ", like this, but using the relevant name:

Oh, this is interesting. "xorg" is not installed. xorg-server is not installed.

Here's the Xorg list that I have ... somehow?

xorg-libice@1.0.10 x11/xorg-libice
xorg-libpthread-stubs  @0.4x11/xorg-libpthread-stubs
xorg-libsm @1.2.3  x11/xorg-libsm
xorg-libX11@1.8x11/xorg-libX11
xorg-libXau@1.0.9  x11/xorg-libXau
xorg-libxcb@1.15   x11/xorg-libxcb
xorg-libXdamage@1.1.5  x11/xorg-libXdamage
xorg-libXdmcp  @1.1.3  x11/xorg-libXdmcp
xorg-libXext   @1.3.4  x11/xorg-libXext
xorg-libXfixes @6.0.0  x11/xorg-libXfixes
xorg-libXi @1.7.10 x11/xorg-libXi
xorg-libXmu@1.1.3  x11/xorg-libXmu
xorg-libXrandr @1.5.2  x11/xorg-libXrandr
xorg-libXt @1.2.1  x11/xorg-libXt
xorg-libXxf86vm@1.1.4  x11/xorg-libXxf86vm
xorg-xcb-proto @1.15   x11/xorg-xcb-proto
xorg-xcb-util  @0.4.0  x11/xorg-xcb-util
xorg-xorgproto     @2022.1 x11/xorg-xorgproto
xrender@0.9.10 x11/xrender

... How do I have some parts of the X libraries without actually having X?

Answer:
keybounceMBP:MacOS michael$ port depend xorg-libX11
gdk-pixbuf2 depends on xorg-libX11
mesa depends on xorg-libX11
xorg-libXext depends on xorg-libX11
xorg-libXfixes depends on xorg-libX11
xorg-libXrandr depends on xorg-libX11
xorg-libXt depends on xorg-libX11
xrender depends on xorg-libX11

keybounceMBP:MacOS michael$ port depend mesa
freeglut depends on mesa
libGLU depends on mesa
webp depends on mesa

keybounceMBP:MacOS michael$ port depend libGLU
freeglut depends on libGLU

keybounceMBP:MacOS michael$ port depend freeglut
webp depends on freeglut

keybounceMBP:MacOS michael$ port depend webp
ImageMagick depends on webp
gd2 depends on webp
graphviz depends on webp
qt5-qtimageformats depends on webp
qt58-qtimageformats depends on webp
keybounceMBP:MacOS michael$ 

So gd2, and others, to webp, to freeglut, to libGLU, to mesa, to the X 
libraries.
And gd2 is -X11.

Freeglut requires X11, it's in the library dependencies. 
Webp, however ... does not list freeglut?

Gd2 needs webp, fine. Webp is somehow grabbing freeglut, despite not listing 
it, and that forces a bunch of X stuff.

Re: A simple request (MkHexGrid) turned into ...

[Michael]

On 2022-05-14, at 9:27 AM, Mojca Miklavec  wrote:

> On Sat, 14 May 2022 at 16:20, Michael wrote:
>> 
>> So I thought I'd install a simple little hex map generator. Mkhexgrid.
>> 
>> Hasn't been updated in years, should be simple, right?
> ...
> You can check why you are getting weird dependency by running the
> following command:
>port rdeps mkhexgrid

Hmm. Just some highlights. It took a compiler??

fontconfig
  expat
  ossp-uuid
perl5.28
  db48
  gdbm
readline

libunistring
  perl5
  texinfo
help2man
  perl5.34
  p5.34-locale-gettext

  libpsl
python310
  libedit
  libffi
expect
  tcl

libheif
  dav1d
clang-14
  cctools
libunwind-headers
llvm-3.7
  llvm_select

  clang-11
clang-9.0
  clang-3.7
  libomp
  llvm-9.0
  clang_select
  ld64
ld64-274
  libmacho-headers

meson
  py39-setuptools
python39

  aom
git
  perl5.26
  python27
openssl11
python2_select

Interestingly, X 11 is not on that list. And Gd2 is installed as non-X:
keybounceMBP:~ michael$ port info gd2
gd2 @2.3.3_1 (graphics)
Variants: universal, (-)x11

Cairo was another port installed, and not on that list. (Checked -- it's 
+quartz -X11)

Re: A simple request (MkHexGrid) turned into ...

[Michael]

On 2022-05-14, at 8:38 AM, Marius Schamschula  wrote:

> Mkhexgrid has not been updated upstream since 2007.

Exactly. So I'm trying to understand how installing something so old/basic like 
that caused a reinstall of so many pieces in Macports.

I was expecting little more than downloading it, and maybe one or two libraries.


> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
> 
>> On May 14, 2022, at 9:20 AM, Michael  wrote:
>> 
>> So I thought I'd install a simple little hex map generator. Mkhexgrid.
>> 
>> Hasn't been updated in years, should be simple, right?
>> 
>> Three versions of Python (37, 38, and 39)
>> A full reinstall of X
>> 
>> I mean, I can sort-of understand perl, one python, and ssl -- maybe it 
>> needed to rebuild something, and needed updated ssh fetching and rebuilding 
>> the compilation environment.
>> 
>> But everything else? And three versions of python? And not just python 2 vs 
>> python 3.
>> 
>> I'm assuming that somewhere, some graphical library was being used that 
>> could output to X as well as to ascii/curses. I just have no idea what. 
>> 
>> All I wanted was to generate a PNG hexmap.
>> At least it was able to fetch binaries for pretty much everything, and not 
>> compile everything.
>> 
> 

---
Entertaining minecraft videos
http://YouTube.com/keybounce

A simple request (MkHexGrid) turned into ...

[Michael]

So I thought I'd install a simple little hex map generator. Mkhexgrid.

Hasn't been updated in years, should be simple, right?

Three versions of Python (37, 38, and 39)
A full reinstall of X

I mean, I can sort-of understand perl, one python, and ssl -- maybe it needed 
to rebuild something, and needed updated ssh fetching and rebuilding the 
compilation environment.

But everything else? And three versions of python? And not just python 2 vs 
python 3.

I'm assuming that somewhere, some graphical library was being used that could 
output to X as well as to ascii/curses. I just have no idea what. 

All I wanted was to generate a PNG hexmap.
At least it was able to fetch binaries for pretty much everything, and not 
compile everything.

Re: Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:

[Michael Newman via macports-users]

Thank you for the explanation. I tried to read the wiki page. Unfortunately, it 
is above my pay grade. I'll have to leave it to someone else to file a ticket.

> On May 7, 2022, at 12:48, Joshua Root  wrote:
> 
> We have a wiki page with an in-depth explanation of what this warning means: 
> 
> 
> The executive summary for end users is that this is something that the port's 
> maintainer needs to look into, so you can file a ticket about it, but it may 
> or may not indicate a significant problem.
> 
> - Josh
> 

Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled:

[Michael Newman via macports-users]

When upgrading MacPorts this morning I noticed the following message wizzing by:

Warning: Configuration logfiles contain indications of 
-Wimplicit-function-declaration; check that features were not accidentally 
disabled:

This right after:

--->  Configuring xorg-libxcb

I've never seen "Wimplicit" used before and wondered what it meant. When I 
searched I got:

Your search - -Wimplicit - did not match any documents.

Can someone please explain what this warning is about and just what "Wimplicit" 
means?

Mike Newman
Korat, Thailand

Re: Changing the install location per OS version (was: During Migration to Arm64 mac, should I null out archs='x86_64' from installed ports list?)

[Michael]

On 2022-04-14, at 3:44 AM, Peter Serocka  wrote:

> A "meta-select" can easily provide /opt/local as symlink to the desired 
> default tree. Another tiny tool can set up $PATH for users at runtime, 
> providing the bin folders from multiple trees (PATH= ... 
> $(/opt/local/bin/mp_paths) ...)

So this discussion of changing things on new installs got me to wonder about 
this.

If the new system has compatibility modes to run older programs in their 
expected environment, and recompile new stuff as needed, what's wrong with this 
approach?

Keep all the existing, working binaries off in /opt/macports/x64-15, put new 
stuff in /opt/macports/arm-2 (or whatever), and have /opt/local just change 
destination targets as needed?

We have various "select" commands for python, etc; how is this idea any 
different?

(I am asking out of ignorance. This is not "I think we should do this". This is 
"why don't we?")

installing py310-jupyter fails: cannot import name 'StaticModule' from 'setuptools.config'

[Corcoran, Michael F. (GSFC-662.0)[CATHOLIC UNIV OF AMERICA] via macports-users]

I was trying to install py310-jupyter  but the install failed when building 
py310-jupyterlab_widgets.  The problem seems to be that the StaticModule 
package is imported by

/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/jupyter_packaging/setupbase.py

but not found in setuptools.config:

from setuptools.config import StaticModule
ImportError: cannot import name 'StaticModule' from 'setuptools.config' 
(/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/setuptools/config/__init__.py)

Any idea how to solve this?

the relevant lines from the main.log file are

:debug:build system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_python_py-jupyterlab_widgets/py310-jupyterlab_widgets/work/jupyterlab_widgets-1.0.2"
 && /opt/local/Library/Frameworks/Python.framework/Versions/3.10/bin/python3.10 
setup.py --no-user-cfg build -j16
:info:build Traceback (most recent call last):
:info:build   File 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_github.com_macports_macports-ports_python_py-jupyterlab_widgets/py310-jupyterlab_widgets/work/jupyterlab_widgets-1.0.2/setup.py",
 line 6, in 
:info:build from jupyter_packaging import (
:info:build   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/jupyter_packaging/__init__.py",
 line 7, in 
:info:build from .setupbase import *
:info:build   File 
"/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/jupyter_packaging/setupbase.py",
 line 38, in 
:info:build from setuptools.config import StaticModule
:info:build ImportError: cannot import name 'StaticModule' from 
'setuptools.config' 
(/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/setuptools/config/__init__.py)

I've filed a ticket but was wondering if anyone on the list had any insight…

thanks

Mike


Dr. Michael F. Corcoran
The Catholic University of America
Goddard Space Flight Center, Code 662
Greenbelt, MD 20771

Re: Hello and my first question (regarding CMAKE_OSX_DEPLOYMENT_TARGET)

[Michael Monschau]

Thanks Ryan,

I just realised, I had this email sitting in my Drafts all this time. Never 
sent it.

I have actually not been able to try your suggestions to this day, as it works 
if I simply ignore the warnings, so it has not been a problem so far. I will 
return to this maybe during the summer as spring for me will be very busy.

Anyway, thanks again. I’ll be in touch.

Kind regards,
Michael

> On 6 Oct 2021, at 00:09, Ryan Schmidt  wrote:
> 
> On Sep 28, 2021, at 05:09, Michael Monschau wrote:
>> 
>> Background:
>> I recently had the need to resort to some open software to add certain PDF 
>> manipulation features to one of my products. The open source tool I am using 
>> is podofo-0.9.7. That uses various other libraries including openssl. As 
>> part of my own XCode project I have to link against crypto.dylib (linking 
>> against the crypto.a library in XCode). 
>> Note: I am using 'port install' with the ‘+universal’ flag as I need 
>> universal libraries
>> 
>> The problem:
>> I am building the macports libraries that I need on macOS 11.4. However, I 
>> need the deployment target for my own xcode projects to be 10.13 and to 
>> avoid hundreds of link warnings which may push out important ones, I need to 
>> rebuild openssl with that deployment target set. I understand there is 
>> CMAKE_OSX_DEPLOYMENT_TARGET and I can do set(CMAKE_OSX_DEPLOYMENT_TARGET 
>> “10.13”), but I don’t know
>>1. where I do this (I was thinking in 
>> '/opt/local/share/cmake-3.20/Modules/Platform/Darwin.cmake' but not sure)
>>2. how to force the rebuilding from source using cmake of the openssl 
>> libraries via 'port install'
> 
> By default MacPorts builds for the current OS deployment target, i.e., if you 
> are on macOS 11.x MacPorts builds for deployment target 11, and if you are on 
> macOS 10.15.x MacPorts builds for deployment target 10.15.
> 
> You can instruct MacPorts to build for a different deployment target by 
> editing macports.conf, e.g.
> 
> macosx_deployment_target 10.13
> 
> If you need to build using a different SDK, you can indicate that too:
> 
> macosx_sdk_version 10.13
> 
> You don't have the 10.13 SDK on a macOS 11 system by default, so you would 
> need to get a copy and put it in the right place 
> (/Library/Developer/CommandLineTools/SDKs/ for ports that build with the 
> command line tools or 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
>  for ports that build with Xcode).
> 
> Because these are undocumented and seldom-used options, you may encounter 
> ports that do not respect these settings. If so, that would be a bug that we 
> should fix and you could file a bug report or pull request, just be prepared 
> for the likelihood of encountering these problems.
> 
> By default MacPorts fetches binaries for ports when it can. Those binaries 
> were built with default deployment target and SDK settings. If you are trying 
> to create a MacPorts installation using different settings for those values, 
> you should uninstall all ports and, before installing any ports, disable the 
> use of binaries by setting "buildfromsource always" in macports.conf.
> 
> You may want to leave your default prefix /opt/local untouched so that it 
> builds with default settings and receives binaries, and set up a second 
> MacPorts prefix somewhere else, such as /opt/local10.13. That way you 
> remember that you've given /opt/local10.13 special settings, and you retain 
> /opt/local and are still able to receive binaries when installing ports that 
> are unrelated to your 10.13 deployment target project.
> 
> Another option if you are just looking for binaries pre-built for specific OS 
> versions is to download them from our packages server, assuming binaries are 
> available. For example, the latest openssl we compiled for macOS 10.13 is 
> currently 
> http://packages.macports.org/openssl/openssl-1.1.1l_1.darwin_17.x86_64.tbz2
> 

Re: certificate update for old Macs

[Michael]

On 2022-01-03, at 4:12 PM, Richard L. Hamilton  wrote:

> The only problem with that or anything similar, is that unless you go to 
> quite a lot of work to just download rather than install the PEM file, and 
> convert it into something human readable WITHOUT installing it, and 
> investigate every certificate in there, you're trusting that the site you got 
> it from is not only legit, but is secure and hasn't been hacked to alter the 
> file to provide some very bogus certificates that could work together with 
> some sort DNS spoofing to get you to feed sensitive information (ie bank 
> passwords, etc) via an untrusted site that would capture it.

Makes sense. Now, how do you go about turning a certificate into something 
human readable? Serious question, I have *never* seen this discussed anywhere.

Everyone just says "As long as the roots are good you can trust the chain", and 
that's never made sense to me. The whole "trust what strangers say" system 
seems more like "Find a way for companies to make money" than any good security 
system.

Re: ffmpeg unexpectedly uninstalled

[Michael Newman via macports-users]

I'm using the -f option because I copied it from some recommendation I read 
somewhere. I'm not smart enough to figure things like this out myself so I 
usually rely on what I find by searching. For years I just ran:

sudo port selfupdate
sudo port upgrade outdated

But then I read somewhere that to remove unneeded junk I should also run:

sudo port -f clean --all all
sudo port -f uninstall inactive
sudo port uninstall leaves

I guess I found out that was wrong. What should I run when I do my periodic 
selfupdate?

And, yes, I'm sure there was not another version of ffmpeg installed. I have a 
shell script that runs daily which uses ffmpeg. When I ran the script after 
updating macports there was an error message about there being no 
/opt/local/bin/ffmpeg. After I installed ffmpeg the script ran OK.

> On Jan 4, 2022, at 08:05, Chris Jones  wrote:
> 
> 
> 
>> On 3 Jan 2022, at 11:54 pm, Michael Newman via macports-users 
>>  wrote:
>> 
>> When I periodically update MacPorts I also run:
>> 
>> sudo port -f uninstall inactive
> 
> Why are you using the -f option here. That could force something to happen 
> that might not be a good idea. Generally speaking you should not use it as a 
> matter of course, and only when you really need to, for some specific reason.
> 
>> 
>> This seemed to work fine until last month when ffmpeg was uninstalled. I 
>> reinstalled and forgot about it.
>> 
>> But, it happened again yesterday:
>> 
>> --->  Deactivating ffmpeg @4.4.1_1+gpl2
>> --->  Cleaning ffmpeg
>> --->  Uninstalling ffmpeg @4.4.1_1+gpl2
>> --->  Cleaning ffmpeg
>> 
>> So, I reinstalled and tried:
>> 
>> MrMuscle:~ mnewman$ sudo port -f uninstall inactive
>> Password:
>> Error: No ports matched the given expression
>> 
>> I checked the "requested" ports here from a file I created for the Big Sur 
>> migration:
>> 
>> MrMuscle:~ mnewman$ ls -la /Users/mnewman/Desktop/requested.txt
>> -rwxrwxrwx@ 1 mnewman  staff  359 Jun  8  2021 
>> /Users/mnewman/Desktop/requested.txt*
>> MrMuscle:~ mnewman$ grep ffmpeg /Users/mnewman/Desktop/requested.txt
>> ffmpeg
>> 
>> So, ffmpeg is definitely a requested port.
>> 
>> I'm baffled. What's going on here?
> 
> Are you sure you don’t still have a version of ffmpeg installed ? The above 
> only temoved inactive ports, it did not uninstall any active ports.
> 
>> 
>> Mike Newman
>> Korat, Thailand
>> 

ffmpeg unexpectedly uninstalled

[Michael Newman via macports-users]

When I periodically update MacPorts I also run:
 
sudo port -f uninstall inactive

This seemed to work fine until last month when ffmpeg was uninstalled. I 
reinstalled and forgot about it.

But, it happened again yesterday:

--->  Deactivating ffmpeg @4.4.1_1+gpl2
--->  Cleaning ffmpeg
--->  Uninstalling ffmpeg @4.4.1_1+gpl2
--->  Cleaning ffmpeg

So, I reinstalled and tried:

MrMuscle:~ mnewman$ sudo port -f uninstall inactive
Password:
Error: No ports matched the given expression

I checked the "requested" ports here from a file I created for the Big Sur 
migration:

MrMuscle:~ mnewman$ ls -la /Users/mnewman/Desktop/requested.txt
-rwxrwxrwx@ 1 mnewman  staff  359 Jun  8  2021 
/Users/mnewman/Desktop/requested.txt*
MrMuscle:~ mnewman$ grep ffmpeg /Users/mnewman/Desktop/requested.txt
ffmpeg

So, ffmpeg is definitely a requested port.

I'm baffled. What's going on here?

Mike Newman
Korat, Thailand

Re: provide latest OS root certificates via port?

[Michael]

So I found this advice online for updating certs without having to worry about 
trusting expired old certs.

1. Visit https://letsencrypt.org/certs/isrgrootx1.pem to download the 
certificate, and save it in the Documents folder.

2. Open Terminal, paste this command, and press enter:

sudo security -v add-trusted-cert -d -r trustRoot -k 
"/Library/Keychains/System.keychain" ~/Documents/isrgrootx1.pem

This eliminates the need for marking the expired DST root as special-case 
trusted.

Re: provide latest OS root certificates via port?

[Michael]

As a user who spent a week trying to figure out what was going on with more and 
more sites not working, making less of the information out there available to 
figure out how to solve the expired cert, it was really painful to find out 
that this was "known in advance", and worse, this implies that ANY "modern", 
"secure" OS is an inherent time-death, for no good reason.

Having an easy way to update certs would be wonderful.
Finding out the hard way that not only did I need to put the DST root in, but 
that in the next year there's a couple more that will expire, when this was 
something that could have, and should have, been made very public in advance, 
was painful.

Discovering the *harder* way that adding a root key to your personal account is 
not the same as adding it system wide, meaning that the first information I got 
wasn't even accurate, only made things worse -- I could browse the web just 
fine, but stuff running as root from launchd was using a different set of certs 
that did not include this.

Some sort of "Warning! This system is considered extremely vulnerable" is fine. 
But we see ATM's running windows XP, voting machines running Vista, etc. Old 
systems being used past their expiration date is normal.

Or do you think that 50 year old FORTRAN programs on 370 systems should be 
retired and the entire financial system forced to rewrite code used all around 
the world?

>  Sometimes, one has to work with what one has.

Exactly.

> On 2021-10-29, at 8:17 AM, Richard Bonomo TDS personal  wrote:
> 
> 
> I don't know what to think about MacPorts, specifically, providing
> new certificates, but, pertaining to some of the arguments presented
> against doing this on old Macs generally, it must be kept in mind
> that some of us -- including yours truly -- have Apple computers that
> CANNOT use newer operating systems or browsers.  Sometimes, one has
> to work with what one has.
> 
> Rich
> 
> - Original Message -
> From: "Bill Cole" 
> To: "macports-users Users" 
> Sent: Friday, October 29, 2021 10:09:45 AM
> Subject: Re: provide latest OS root certificates via port?
> 
> On 2021-10-29 at 07:23:38 UTC-0400 (Fri, 29 Oct 2021 07:23:38 -0400)
> Richard L. Hamilton 
> is rumored to have said:
> 
>> You're (probably - seems plausible but I haven't verified it myself) 
>> right that that's annoying and fixable.
>> 
>> But there's a big reason to think carefully about whether to do that. 
>> If something is old enough that it isn't receiving certificate 
>> updates, it probably isn't receiving security updates either. And the 
>> same applications and functionality that need current root 
>> certificates to work are also likely to be common attack points.
>> 
>> So at the very least, anything that makes it easier to take such a 
>> risk should come with a prominent warning, IMO.
> 
> Yes: Anyone running Mojave or earlier is not exactly skydiving without a 
> parachute, but is doing something close. Perhaps it's akin to skydiving 
> with a homemade parachute...
> 
> Frankly, I don't think MacPorts should attempt to 'fix' this issue or 
> similar future issues diretly, not because it encourages risky behavior 
> but because MacPorts should avoid poking around in the MacOS base at all 
> where it isn't essential for the operation of MacPorts. It's easy enough 
> in principle for MacPorts to stand up and use its own modern OSS-based 
> encryption+PKI stack with its own set of trusted CAs (e.g. 
> curl-ca-bundle and openssl ports) and so keep itself functional without 
> poking around in core functionality of the OS that MacPorts-naive tools 
> need to use. People who need to fix the problem of an expired root cert 
> should be able to understand and repair that problem (which can be done 
> without digging a CA bundle out of a newer system) if they need to, and 
> having the issue unaddressed is not itself a security issue, but a 
> functionality issue. Anyone who actually wants to run Safari & Chrome on 
> an OS that isn't getting basic security maintenance should be thinking 
> very carefully about what they are doing and accept responsibility for 
> making something work which arguably should no longer work because it is 
> too risky.
> 
> One risk for MacPorts is a slippery slope created by providing support 
> for antique OS versions that include opaque proprietary bits that are 
> probably insecure in ways that no one fully understands. If it is taken 
> too far (which in my opinion includes fixing core components like PKI) 
> MP would be doing a disservice to users who understandably expect a 
> "Just Works" experience on a Mac by enabling the continued use of tools 
> that could well have permanent unrecognized and mostly invisible 
> security flaws.
> 
> 
>>> On Oct 29, 2021, at 07:12, René J.V. Bertin  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> Users of older Apple OSes that are no longer receiving updates 
>>> probably noticed that Safari and Chrome-based browsers no longer 
>>> connect to lots o

Re: Error: Failed to build librsvg: command execution failed

[Michael Newman via macports-users]

> On Oct 13, 2021, at 20:28, Christopher Jones  wrote:
> 
> In the meantime if you are in a hurry installing macports clang 11 should 
> also fix things.

I wasn't in a hurry, but I wanted to try this. It worked. 

Thank you very much.

Mike

Re: Error: Failed to build librsvg: command execution failed

[Michael Newman via macports-users]

> On Oct 13, 2021, at 18:12, Lenore Horner  wrote:
> 
> Do you have /opt/local/bin/clang-mp-11? 

Axe:~ mnewman$ ls /opt/local/bin/clang-mp-11
ls: /opt/local/bin/clang-mp-11: No such file or directory


> On Oct 13, 2021, at 19:31, Christopher Jones  wrote:
> 
> oh, and to be sure please first run `sudo port sync` t make sure your ports 
> are fully up to date….

Axe:~ mnewman$ sudo port sync
Password:
--->  Updating the ports tree
Error: Synchronization of the local ports tree failed doing rsync
port sync failed: Synchronization of 1 source failed


> On Oct 13, 2021, at 19:30, Christopher Jones  wrote:
> 
> Please run `port info librsvg rust` and post what that returns.

Axe:~ mnewman$ port info librsvg rust
librsvg @2.52.1_1 (graphics, gnome)
Variants: quartz, universal, x11

Description:  GNOME implementation of rsvg.
Homepage: https://wiki.gnome.org/Projects/LibRsvg

Extract Dependencies: xz
Build Dependencies:   pkgconfig, rust, cargo
Library Dependencies: glib2, cairo, pango, gdk-pixbuf2, libxml2, vala,
  gobject-introspection
Platforms:darwin
License:  (GPL-2+ or LGPL-2+)
Maintainers:  Email: dev...@macports.org, GitHub: dbevans
  Email: masc...@macports.org, GitHub: mascguy
  Policy: openmaintainer
--
rust @1.55.0_3 (lang, devel)
Sub-ports:rust-compiler-wrap, rust-src

Description:  Rust is a curly-brace, block-structured expression
  language. It visually resembles the C language family, but
  differs significantly in syntactic and semantic details.
  Its design is oriented toward concerns of "programming in
  the large", that is, of creating and maintaining
  boundaries -- both abstract and operational -- that
  preserve large-system integrity, availability and
  concurrency.
Homepage: https://www.rust-lang.org

Build Dependencies:   git, cmake, cctools, python39, openssl, pkgconfig, ninja,
  gmake
Library Dependencies: libffi, libgit2, openssl
Platforms:darwin
License:  (MIT or Apache-2) and BSD and zlib and NCSA and Permissive
Maintainers:  Email: g...@macports.org, GitHub: g5pw
  Email: herby.gil...@gmail.com, GitHub: herbygillot
  Policy: openmaintainer

Error: Failed to build librsvg: command execution failed

[Michael Newman via macports-users]

Old 2010 MacBook Air on: 10.13.6
MacPorts: 2.7.1
CLTools: 10.1.0.0.1.1539992718

Here's the error:

Error: Failed to build librsvg: command execution failed
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_librsvg/librsvg/main.log
 for details.

I looked at the log, but it's above my pay grade.

Log is here: https://pastebin.com/ncBFApfH 

A bug report (#56192 ) was opened on 
this but closed:  Resolution: → fixed

Quite a few ports depend on librsvg:

Axe:~ mnewman$ port echo depends:librsvg | wc -l
  65

I have no idea what to do next.

Mike Newman
Korat, Thailand

Re: Let's Encrypt DST Root CA X3 Expiration

[Michael]

(Moving from macports to macos-talk)

I am still having a problem with this.
I've managed to get the DST root into my system as "trusted for all users".
But the ISRG root is only marked as "trusted for this account" as my normal 
user ID, and it fails to authenticate for a process that runs as root.

Attempting this security command --
>  sudo security -v add-trusted-cert -d -r trustRoot -k 
> /System/Library/Keychains/SystemRootCertificates.keychain isrgrootx1.pem

does not change it from "this account" to "all users", and I cannot figure out 
how to make that change.

Can anyone help me?

On 2021-10-02, at 8:25 PM, raf  wrote:

> On Sat, Oct 02, 2021 at 08:06:27PM -0700, Michael  wrote:
> 
>> So, first, I want to say "Thank you" for this bit:
>> 
>>> • From View menu select "Show Expired Certificates"
>> 
>> In keychain access, I could not see the expired certs, and was
>> thinking that they were just deleted for being old. Once I could find
>> the old ones, I could turn them back on.
> 
> Ah, that explains why I couldn't see it. :-)
> 
>> The second thing is that for whatever reason, I could not download
>> and install the new cert into keychain access. But ... oddly, Firefox
>> 52 ESR had that cert installed (even that old ...???). I could export
>> from firefox, and import THAT into keychain access, and at least
>> enable that for my account.
>> 
>> So, ... well, not perfect. These certs are marked as trusted for *my
>> account*. Not for the system. So predictably, some things done by the
>> system in the background will fail, but at least Chrome and Firefox
>> both now work fine. (Safari isn't tested, but ... well, Safari isn't
>> tested :=-).
> 
> On 10.6.8, I wasn't able to add to the system keychain
> via the Keychain Access GUI (even after unlocking it),
> but I was able to do it using the "security" command
> following these instructions:
> 
>  How do I update my root certificates on an older version of Mac OS (e.g. El 
> Capitan)?
>  
> https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
> 
> If you have ISRG Root X1 as a .pem file, something like this
> should import it into the "System" keychain:
> 
>  sudo security -v add-trusted-cert -d -r trustRoot -k 
> /Library/Keychains/System.keychain isrgrootx1.pem
> 
> For the "System Roots" keychain, instead of the "System" keychain:
> 
>  sudo security -v add-trusted-cert -d -r trustRoot -k 
> /System/Library/Keychains/SystemRootCertificates.keychain isrgrootx1.pem
> 
> I don't know if it matters which of these keychains it goes into.
> 
> cheers,
> raf

---
This message was composed with the aid of a laptop cat, and no mouse

Re: Let's Encrypt DST Root CA X3 Expiration

[Michael]

ugh. Well, doing a search shows a LOT of articles about this very issue -- this 
was apparently a known "this is going to affect a lot of people" deal, and 
"just update your software, or ... sorry." was the only answer.

But, I at least did find out why certs expire. 
Seriously though: A cert identifies a domain. If you sell/buy a domain, you 
want to be able to invalidate all existing certs for that domain.

And as I see that, I'm immediately struck by two things:
1. SSL, and a cert's job, is to validate the connection, not the person on the 
other end. It's to prevent MitM attacks. (Putting the domain name in -- when 
multiple names can go to the same server? Why?)
2. The DNS is the obvious place to put "Here's our fingerprint" or something to 
validate a cert -- that would prevent old owner certs from working. (So why 
isn't this done?)

And I cannot find any good reason for expiring root certs. They explicitly have 
much longer lifespans than anything else, and this isn't the first time that 
root certs have gone poof.

Off the list topic now. Thanks for  your help.

On 2021-10-02, at 8:32 PM, Ryan Schmidt  wrote:

> On Oct 2, 2021, at 22:06, Michael wrote:
>> 
>> So, first, I want to say "Thank you" for this bit:
>> 
>>> • From View menu select "Show Expired Certificates"
>> 
>> In keychain access, I could not see the expired certs, and was thinking that 
>> they were just deleted for being old. Once I could find the old ones, I 
>> could turn them back on.
>> 
>> The second thing is that for whatever reason, I could not download and 
>> install the new cert into keychain access. But ... oddly, Firefox 52 ESR had 
>> that cert installed (even that old ...???). I could export from firefox, and 
>> import THAT into keychain access, and at least enable that for my account.
>> 
>> So, ... well, not perfect. These certs are marked as trusted for *my 
>> account*. Not for the system. So predictably, some things done by the system 
>> in the background will fail, but at least Chrome and Firefox both now work 
>> fine. (Safari isn't tested, but ... well, Safari isn't tested :=-).
>> 
>> 
>> 
>> I have a much better question, that's outside of the scope of this list or 
>> even the site(s) in question.
>> 
>> Why does a signature expire?
>> 
>> If I have something that was signed by a cert, and it was signed in a valid 
>> time time stamp, why does that signature ever expire?
>> 
>> I've come across programs that have an expired signature, and I can't see a 
>> good reason for it.
>> 
>> And if  there's no good way to tell when something was actually signed 
>> (because a timestamp can be forged), then the question becomes, why does a 
>> cert expire as a function of time? Why not allow a cert to be "until 
>> revoked"? 
>> 
>> For that matter, why is "valid/not valid" not under the control of the 
>> system? Why is someone else allowed to say that my system is no longer valid?
>> 
>> I figure that there's a good answer to these questions somewhere, but I have 
>> no clue where to even begin looking. And yes, I know that quantum factoring 
>> will eventually permit all of these certs to be forged, but until then, why 
>> not allow them, and even after that point, why not allow me to allow them?
> 
> I'm not an expert on this stuff, just sharing what I learned about the issue 
> yesterday, but you can ask your search engine questions like "why do 
> certificates expire" or more specifically in this case "why do root ca 
> certificates expire".
> 
> My understanding is that the reason why Let's Encrypt recommends sites 
> continue to serve the ISRG Root X1 certificate that is signed by the expired 
> DST Root CA X3 certificate is that at least old browsers like those on old 
> Android phones should consider a web site's certificate to be valid, as long 
> as we are within its validity dates, even if the root certificate it's signed 
> by is expired. Like I said, I'm not an expert, I don't know why it would be 
> that way, and evidently it's not that way on some Apple devices, so server 
> administrators now have to choose between Let's Encrypt's default which 
> supports old Android devices or the other way which supports old Apple 
> devices.
> 
> 

---
Entertaining minecraft videos
http://YouTube.com/keybounce

Re: Let's Encrypt DST Root CA X3 Expiration

[Michael]

So, first, I want to say "Thank you" for this bit:

> • From View menu select "Show Expired Certificates"

In keychain access, I could not see the expired certs, and was thinking that 
they were just deleted for being old. Once I could find the old ones, I could 
turn them back on.

The second thing is that for whatever reason, I could not download and install 
the new cert into keychain access. But ... oddly, Firefox 52 ESR had that cert 
installed (even that old ...???). I could export from firefox, and import THAT 
into keychain access, and at least enable that for my account.

So, ... well, not perfect. These certs are marked as trusted for *my account*. 
Not for the system. So predictably, some things done by the system in the 
background will fail, but at least Chrome and Firefox both now work fine. 
(Safari isn't tested, but ... well, Safari isn't tested :=-).



I have a much better question, that's outside of the scope of this list or even 
the site(s) in question.

Why does a signature expire?

If I have something that was signed by a cert, and it was signed in a valid 
time time stamp, why does that signature ever expire?

I've come across programs that have an expired signature, and I can't see a 
good reason for it.

And if  there's no good way to tell when something was actually signed (because 
a timestamp can be forged), then the question becomes, why does a cert expire 
as a function of time? Why not allow a cert to be "until revoked"? 

For that matter, why is "valid/not valid" not under the control of the system? 
Why is someone else allowed to say that my system is no longer valid?

I figure that there's a good answer to these questions somewhere, but I have no 
clue where to even begin looking. And yes, I know that quantum factoring will 
eventually permit all of these certs to be forged, but until then, why not 
allow them, and even after that point, why not allow me to allow them?

On 2021-10-02, at 7:52 PM, Ryan Schmidt  wrote:

> On Oct 2, 2021, at 10:57, Michael wrote:
>> 
>> Well, thank you for this, and it explains something else.
>> 
>> I've got an older OS (10.9.5), and suddenly Chrome (67 is latest here) has 
>> been complaining left right and center about LOTS of unsafe sites, refusing 
>> to let me connect, etc. Meanwhile, firefox (52 esr) is happy to connect, but 
>> is too old to display a lot of them correctly.
>> 
>> Is there any way for older OS's to declare extended trust for certificates?
> 
> I've added instructions for doing that here:
> 
> https://trac.macports.org/wiki/ProblemHotlist#letsencrypt
> 
> It helped Safari and /usr/bin/curl. I didn't test Chrome; you can let us know 
> if it helps.

---
This message was composed with the aid of a laptop cat, and no mouse

Hello and my first question (regarding CMAKE_OSX_DEPLOYMENT_TARGET)

[Michael Monschau]

Hi Everyone,

I am fairly new to macports. I build and license development software for a 
niche marked (I develop plugin tools for the RAD Development Tool Omnis 
Studio). I am based in the UK.

Background:
I recently had the need to resort to some open software to add certain PDF 
manipulation features to one of my products. The open source tool I am using is 
podofo-0.9.7. That uses various other libraries including openssl. As part of 
my own XCode project I have to link against crypto.dylib (linking against the 
crypto.a library in XCode). 
Note: I am using 'port install' with the ‘+universal’ flag as I need universal 
libraries

The problem:
I am building the macports libraries that I need on macOS 11.4. However, I need 
the deployment target for my own xcode projects to be 10.13 and to avoid 
hundreds of link warnings which may push out important ones, I need to rebuild 
openssl with that deployment target set. I understand there is 
CMAKE_OSX_DEPLOYMENT_TARGET and I can do set(CMAKE_OSX_DEPLOYMENT_TARGET 
“10.13”), but I don’t know
 1. where I do this (I was thinking in 
'/opt/local/share/cmake-3.20/Modules/Platform/Darwin.cmake' but not sure)
 2. how to force the rebuilding from source using cmake of the openssl 
libraries via 'port install'

Many thanks for any answers that yo can provide

Kind regards,
Michael

web: www.brainydata.com

Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration

[Michael Newman via macports-users]

Today I finally installed Big Sur and followed the MacPorts migration guide. I 
don't see any errors; no failures to build. However, I did get seven of these 
warnings:

Warning: Configuration logfiles contain indications of 
-Wimplicit-function-declaration; check that features were not accidentally 
disabled:

It was found in the following logs:

lynx2.8.9rel.1/config.log
clamav-0.103.2/config.log
anholt-libepoxy-d51a358/config.log
ghostpdl-9.54.0/config.log
graphviz-2.40.1/config.log
gst-libav-1.16.2/config.log
gst-plugins-bad-1.16.2/config.log

I have no idea what a "Wimplicit-function-declaration" is. I tried to search 
around, but was unable to enlighten myself. I gather it has something to do 
with C; about which I know nothing. If this warning is explained somewhere, 
please provide me with a link.

Do I need to do something about these, or are they ignorable?

Mike Newman
Korat, Thailand

Warning: cltversion:....

[Michael Newman via macports-users]

This happens both on a 2017 iMac running Catalina and a 2010 MBA running High 
Sierra.

Every time I run "sudo port upgrade outdated" I get the message about the 
command line tools:

"Warning: cltversion: The Command Line Tools are installed, but MacPorts cannot 
determine the version."

I follow the instructions here:

https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt 


This is the iMac:

MrMuscle:volumes mnewman$ touch 
/tmp/.com.apple.dt.CommandLineTools.installondemand.in-progress
MrMuscle:volumes mnewman$ softwareupdate -l
Software Update Tool
Finding available software
Software Update found the following new or updated software:
* Label: Command Line Tools for Xcode-12.4
Title: Command Line Tools for Xcode, Version: 12.4, Size: 440392K, 
Recommended: YES,
MrMuscle:volumes mnewman$ rm 
/tmp/.com.apple.dt.CommandLineTools.installondemand.in-progress
MrMuscle:volumes mnewman$ softwareupdate -l
Software Update Tool
Finding available software
No new software available.
MrMuscle:volumes mnewman$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 12.4.0.0.1.1610135815
volume: /
location: /
install-time: 1622628917
groups: com.apple.FindSystemFiles.pkg-group

But it doesn't seem to "stick" and the next time it shows up again.

What am I doing wrong?

Mike Newman
Korat, Thailand

Re: Build servers offline due to failed SSD

[Michael A. Leonetti via macports-users]

I’d really love to know more about what you’re saying here. Up until I just 
read what you wrote, I thought SSDs were the savior of HDDs.

Michael A. Leonetti
As warm as green tea

> 3/7/21 午後5:26、Dave Horsfall のメール:
> 
> On Sat, 6 Mar 2021, Dave C via macports-users wrote:
> 
>> Isn’t SSD a bad choice for server duty? No server farms use them, apparently 
>> due to short lifespan.
> 
> If you knew how SSDs worked then you wouldn't use them at all without many 
> backups.  Give me spinning rust any day...
> 
> -- Dave

Re: Build servers going offline due to inclement weather

[Michael A. Leonetti via macports-users]

Best mailing list ever?

Michael A. Leonetti
As warm as green tea

On 2/17/21 10:58 PM, Dave Horsfall wrote:

On Wed, 17 Feb 2021, Richard Bonomo TDS personal wrote:

I work in Nuclear Fusion, as that is really the only truly long-term 
(centuries, millennia) way to power a technically advanced and 
populous society.


Agreed.

-- Dave

Re: Warning: All compilers are either blacklisted or unavailable

[Michael Newman via macports-users]

On Jan 1, 2021, at 01:47, Ryan Schmidt  wrote:

> If you see this warning when doing actions other than 
> configuring/building/installing (such as when cleaning) ignore it. Maybe we 
> shouldn't even display the warning in those cases, though I'm not sure if 
> there's a good way for us to do that.
> 

> 
> File a bug report and provide as much information as possible about your OS 
> version, Xcode version, and which compiler got used.

As always, thank you for the clear and comprehensive explanation written in 
such a way that even I can understand it. 

Happy New Year

Mike Newman
Korat, Thailand

Warning: All compilers are either blacklisted or unavailable

[Michael Newman via macports-users]

Some months ago I upgraded the OS on a remote 2010 MacBook (the white one) to 
High Sierra (10.13.16). After the upgrade I did the recommended MacPorts 
migration without problems.

I don’t visit this machine very regularly, so only recently remembered to run 
port clean all after doing a selfupdate/upgrade. Both of the latter ran without 
error, but the clean produced many like the following:

--->  Cleaning wxsvg
Warning: All compilers are either blacklisted or unavailable; defaulting to 
first fallback option

I’m not sure how to deal with this. There’s no indication that any ports failed 
to build, but the presence of the warning bothers me. I don’t see any recent 
list mentions of this issue.

Is there anything that I should do?

(Sorry for the New Year’s Eve interruption.)

Mike Newman
Korat, Thailand

Re: Using X11 for an older program

[Michael]

On 2020-12-25, at 7:27 PM, Peter West  wrote:

> Thanks for that, Michael.
> 
> God bless you.

I do my best to bring humor wherever I can, no matter how silly it may seem.

> --
> Peter West
> p...@pbw.id.au
> “The Word was made flesh, he lived among us…”
> 
>> On 26 Dec 2020, at 12:47 pm, Michael  wrote:
>> 
>> 
>> On 2020-12-25, at 5:10 PM, Ken Cunningham  
>> wrote:
>>> 
>>> Oh, you have nothing to lose trying it.
>>> 
>>> If it doesn’t work, just set it back.
>>> 
>>> you can’t break anything. It’s just a computer, and it does what you tell 
>>> it to do.
>> 
>> You'd be amazed at how that's no longer true. My iPhone refuses to do what I 
>> tell it, it insists that it knows more than me.

---
This message was composed with the aid of a laptop cat, and no mouse

Re: Using X11 for an older program

[Michael]

On 2020-12-25, at 5:10 PM, Ken Cunningham  
wrote:
> 
> Oh, you have nothing to lose trying it.
> 
> If it doesn’t work, just set it back.
> 
> you can’t break anything. It’s just a computer, and it does what you tell it 
> to do.

You'd be amazed at how that's no longer true. My iPhone refuses to do what I 
tell it, it insists that it knows more than me.

---
This message was composed with the aid of a laptop cat, and no mouse

Re: Using X11 for an older program

[Michael]

On 2020-12-21, at 8:38 PM, Ken Cunningham  
wrote:

> A thought — perhaps you might just take the easy road, and install the 
> libraries it is looking for, in /opt/X11
> 
> what is that, XQuartz? 

Except that the current version of XQuartz is, as I understand it, what 
Macports provides.

i.e. -- my choice is either an 8 year old apple build, or a current Macport 
build.

(If I'm wrong here, please tell me.)

> 
> K
> 
>> On Dec 21, 2020, at 7:01 PM, Michael  wrote:
>> 
>> OK. Next question: Is there any reason I cannot install libpng version 15 at 
>> the sametime?
>> 
>> I am aware that there is a non-versioned link file, that the latest version 
>> of the dynamic library installs. That can stay at 16 where it belongs. I 
>> mean specifically having both the libpng15 and the libpng16 files.
>> 
>> I am very surprised at linking to a specific version of a dynamic library. 
>> This is actually commercial software, and it did not link to generic 
>> "libpng", nor to generic "libpng15" -- linking to a specific version of a 
>> dynamic library? Isn't the whole point of dynamic libraries that you don't 
>> get a single specific buggy version, but the latest non-buggy version?
>> 
>> On 2020-12-21, at 6:55 PM, Ken Cunningham  
>> wrote:
>> 
>>>> On 2020-12-21, at 10:55 AM, Michael  wrote: > This 
>>>> should be a simple one. I hope. 
>>>>> 
>>>>> I just installed a program that was compiled against the release version 
>>>>> of mac's X11. Crashes on startup with this: 
>>>>> 
>>>>> dyld: launch, loading dependent libraries 
>>>>> 
>>>>> Dyld Error Message: 
>>>>> Library not loaded: /opt/X11/lib/libpng15.15.dylib 
>>>>> 
>>>>> What symbolic links do I need? /opt has no X11 directory. 
>>>> Ok, another question. I found this: /opt/local/lib/libpng16.16.dylib I 
>>>> cannot find the older version. What do I need to do to install both the 
>>>> current and the older version of this library at the same time? 
>>> 
>>> There are likely to be more libraries missing after you fix this one, but 
>>> you can try.
>>> 
>>> EIther symlink a real library that is the same or as similar as you have 
>>> into the position being looked for:
>>> 
>>> sudo ln -s /opt/local/lib/libpng16.16.dylib /opt/X11/lib/libpng15.15.dylib
>>> 
>>> or
>>> 
>>> use install_name_tool to change /opt/local/lib/libpng16.16.dylib to 
>>> /opt/X11/lib/libpng15.15.dylib in your binary.
>>> 
>>> install_name_tool -change  /opt/local/lib/libpng16.16.dylib 
>>> /opt/X11/lib/libpng15.15.dylib /path/to/my/binary
>>> 
>>> 
>>> You can see that there are many many ways this could break / not work at 
>>> all. 
>>> 
>>> But it sometimes works, if you’re lucky, and the libraries are very close 
>>> to what is being looked for.
>>> 
>>> K
>> 
>> ---
>> This message was composed with the aid of a laptop cat, and no mouse
>> 
> 

---
Entertaining minecraft videos
http://YouTube.com/keybounce

Re: Using X11 for an older program

[Michael]

OK. Next question: Is there any reason I cannot install libpng version 15 at 
the sametime?

I am aware that there is a non-versioned link file, that the latest version of 
the dynamic library installs. That can stay at 16 where it belongs. I mean 
specifically having both the libpng15 and the libpng16 files.

I am very surprised at linking to a specific version of a dynamic library. This 
is actually commercial software, and it did not link to generic "libpng", nor 
to generic "libpng15" -- linking to a specific version of a dynamic library? 
Isn't the whole point of dynamic libraries that you don't get a single specific 
buggy version, but the latest non-buggy version?

On 2020-12-21, at 6:55 PM, Ken Cunningham  
wrote:

>> On 2020-12-21, at 10:55 AM, Michael  wrote: > This 
>> should be a simple one. I hope. 
>>> 
>>> I just installed a program that was compiled against the release version of 
>>> mac's X11. Crashes on startup with this: 
>>> 
>>> dyld: launch, loading dependent libraries 
>>> 
>>> Dyld Error Message: 
>>> Library not loaded: /opt/X11/lib/libpng15.15.dylib 
>>> 
>>> What symbolic links do I need? /opt has no X11 directory. 
>> Ok, another question. I found this: /opt/local/lib/libpng16.16.dylib I 
>> cannot find the older version. What do I need to do to install both the 
>> current and the older version of this library at the same time? 
> 
> There are likely to be more libraries missing after you fix this one, but you 
> can try.
> 
> EIther symlink a real library that is the same or as similar as you have into 
> the position being looked for:
> 
> sudo ln -s /opt/local/lib/libpng16.16.dylib /opt/X11/lib/libpng15.15.dylib
> 
> or
> 
> use install_name_tool to change /opt/local/lib/libpng16.16.dylib to 
> /opt/X11/lib/libpng15.15.dylib in your binary.
> 
> install_name_tool -change  /opt/local/lib/libpng16.16.dylib 
> /opt/X11/lib/libpng15.15.dylib /path/to/my/binary
> 
> 
> You can see that there are many many ways this could break / not work at all. 
> 
> But it sometimes works, if you’re lucky, and the libraries are very close to 
> what is being looked for.
> 
> K

---
This message was composed with the aid of a laptop cat, and no mouse

Re: Using X11 for an older program

[Michael]

On 2020-12-21, at 10:55 AM, Michael  wrote:

> This should be a simple one. I hope.
> 
> I just installed a program that was compiled against the release version of 
> mac's X11. Crashes on startup with this:
> 
> dyld: launch, loading dependent libraries
> 
> Dyld Error Message:
> Library not loaded: /opt/X11/lib/libpng15.15.dylib
> 
> What symbolic links do I need? /opt has no X11 directory.

Ok, another question. I found this:

/opt/local/lib/libpng16.16.dylib

I cannot find the older version. What do I need to do to install both the 
current and the older version of this library at the same time?

Using X11 for an older program

[Michael]

This should be a simple one. I hope.

I just installed a program that was compiled against the release version of 
mac's X11. Crashes on startup with this:

dyld: launch, loading dependent libraries

Dyld Error Message:
 Library not loaded: /opt/X11/lib/libpng15.15.dylib

What symbolic links do I need? /opt has no X11 directory.

Confused about build dependencies here

[Michael]

Ok, this seems ... odd. I didn't know about Supertux until I saw it mentioned, 
and figured it seemed like a good game.

> bash-3.2# port install supertux
> --->  Computing dependencies for supertux
> The following dependencies will be installed: 
>  boost
>  clang-9.0
>  clang_select
>  cmake
>  glew
>  ld64
>  ld64-274
>  libomp
>  libraqm
>  libsdl2_image
>  libuv
>  llvm-3.7
>  llvm-9.0
>  lzma
>  physfs
>  xar

Why is it installing llvm for both 3.7 AND 9.0? 

(And yes, reclaim did wipe out all sorts of build builds.)

More old upgrade issues (was: Re: Libgcc: new version won't deactivate the old version)

[Michael]

On 2020-12-04, at 6:24 PM, Ryan Schmidt  wrote:

> On Dec 4, 2020, at 02:58, Christopher Jones wrote:
> 
>> That particular message can only occur if you have not updated your ports in 
>> a very long time, as the change that made libgcc a stub port happened 
>> several years ago now If you don’t update regularly you can run into 
>> issues like this.
>> 
>> In this case, just follow the instructions as given and force deactivate.

Well, I seem to have found more "long time" non-upgrade problems.
A "port reclaim" got rid of most of the problems. Most.

> bash-3.2# port upgrade outdated
> --->  Computing dependencies for curl
> --->  Fetching archive for curl
> --->  Attempting to fetch curl-7.73.0_1+ssl.darwin_13.x86_64.tbz2 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/curl
> --->  Attempting to fetch curl-7.73.0_1+ssl.darwin_13.x86_64.tbz2.rmd160 from 
> https://ywg.ca.packages.macports.org/mirror/macports/packages/curl
> --->  Installing curl @7.73.0_1+ssl
> --->  Cleaning curl
> --->  Computing dependencies for curl
> --->  Deactivating curl @7.73.0_0+ssl
> --->  Cleaning curl
> --->  Activating curl @7.73.0_1+ssl
> --->  Cleaning curl
> 
> Error: Can't install oniguruma6 because conflicting ports are active: 
> oniguruma5
> Error: Problem while installing oniguruma6
> Error: Follow https://guide.macports.org/#project.tickets to report a bug.
> bash-3.2# 

What is "Oniguruma", and what do I need to worry about here?

> Description:  Oniguruma is a regular expressions library in which 
> different character encoding can be specified for every expression. Supports 
> Unicode Porperty/Script.

... does this mean that the normal RE libraries assume a single encoding for 
everything? Like if you work with UTF-8 text, you can't then use windows- or 
UTF-16 text encodings without restarting the program?

Libgcc: new version won't deactivate the old version

[Michael]

> --->  Computing dependencies for libgcc
> The following dependencies will be installed:  libgcc10
> Continue? [Y/n]: y
> --->  Activating libgcc10 @10.2.0_3
> Error: Failed to activate libgcc10: Image error: 
> /opt/local/include/gcc/c++/algorithm is being used by the active libgcc port. 
>  Please deactivate this port first, or use 'port -f activate libgcc10' to 
> force the activation.

Is there a reason that trying to activate the new libgcc does not deactivate 
the old libgcc?

Removing all non-requested ports?

[Michael]

What's the command to remove non-requested ports again?

Re: Failure to compile Poppler - 10.5

[Michael Dickens]

These should take care of the vast majority of the poppler / GO-I issues

https://github.com/macports/macports-ports/pull/8779
https://github.com/macports/macports-ports/pull/8780

I might have overlooked something. Please test / verify! - MLD

On Wed, Oct 14, 2020, at 6:06 AM, Ryan Schmidt wrote:
> 
> 
> On Oct 9, 2020, at 13:50, Ken Cunningham wrote:
> 
> > Punt to the maintainer -- Dave -- to put on his "someday" list.
> 
> Filed: https://trac.macports.org/ticket/61316
> 
>

Re: GTK3 upgrade issue on Mojave

[Michael Dickens]

Hi Greg - You need to reinstall the "at-spi2-atk" port. For example:
{{{
sudo port -f uninstall at-spi2-atk
sudo port install at-spi2-atk
sudo port clean gtk3
sudo port upgrade gtk3
}}}
This worked for me recently. I hope it does for you too! - MLD

On Wed, Oct 14, 2020, at 10:41 AM, Greg Earle wrote:
> All,
> 
> I have this version of GTK3 installed on my Mojave system:
> 
> --
> mojave:~ root# port installed gtk3
> The following ports are currently installed:
>gtk3 @3.24.20_0+universal+x11 (active)
> --
> 
> Trying to do a "port upgraded outdated" to upgrade it to 
> @3.24.23_0+universal+x11 worked fine on my Sierra system, but it runs 
> aground on Mojave with this error:
> 
> --
> [...]
> :info:build libtool: link: /usr/bin/clang -arch x86_64 -o 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gtk3/gtk3/work/gtk+-3.24.23-x86_64/gtk/tmp-introspecto21ooyrl/.libs/Gtk-3.0
>  
> -I/opt/local/include -DX_LOCALE -pipe -Os -fstrict-aliasing -arch 
> x86_64 
> -Wall 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gtk3/gtk3/work/gtk+-3.24.23-x86_64/gtk/tmp-introspecto21ooyrl/Gtk-3.0.o
>  
> -Wl,-framework -Wl,CoreFoundation -Wl,-headerpad_max_install_names 
> -arch 
> x86_64  -L. ./.libs/libgtk-3.dylib -L/opt/local/lib 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gtk3/gtk3/work/gtk+-3.24.23-x86_64/gdk/.libs/libgdk-3.dylib
>  
> -latk-1.0 -latk-bridge-2.0 -lharfbuzz -lpangoft2-1.0 
> ../gdk/.libs/libgdk-3.dylib -lpangocairo-1.0 -lpango-1.0 
> -lgdk_pixbuf-2.0 -lcairo-gobject -lfontconfig -lfreetype -lXinerama 
> -lXi 
> -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lcairo -lX11 -lXext 
> -lepoxy -lfribidi -lm -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 
> -lintl
> 
> :info:build dyld: Library not loaded: @rpath/libatk-bridge-2.0.0.dylib
> 
> :info:build   Referenced from: 
> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gtk3/gtk3/work/gtk+-3.24.23-x86_64/gtk/tmp-introspecto21ooyrl/.libs/Gtk-3.0
> 
> :info:build   Reason: image not found
> 
> :info:build gtkentry.c:2104: Warning: Gtk: multiple comment blocks 
> documenting 'GtkEntry:inner-border:' identifier (already seen at 
> gtkentry.c:888).
> 
> :info:build warning: unknown install library directory! GObject 
> Introspection GIR and TYPELIB files might not work!
> 
> :info:build Command 
> '['/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gtk3/gtk3/work/gtk+-3.24.23-x86_64/gtk/tmp-introspecto21ooyrl/Gtk-3.0',
>  
> '--introspect-dump=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gtk3/gtk3/work/gtk+-3.24.23-x86_64/gtk/tmp-introspecto21ooyrl/functions.txt,/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gtk3/gtk3/work/gtk+-3.24.23-x86_64/gtk/tmp-introspecto21ooyrl/dump.xml']'
>  
> died with .
> 
> :info:build make[3]: *** [Gtk-3.0.gir] Error 1
> --
> 
> Port "atk" is installed and was recently updated.
> 
> libatk-bridge-2.0.0.dylib is there:
> 
> --
> mojave:~ root# port installed atk
> The following ports are currently installed:
>atk @2.36.0_0+universal (active)
> 
> mojave:~ root# ls -l /opt/local/lib/libatk-bridge-2.0.0.dylib
> -rwxr-xr-x  1 root  wheel  224344 Oct  9 07:46 
> /opt/local/lib/libatk-bridge-2.0.0.dylib
> --
> 
> so I'm at a loss to understand what '@rpath' is set to at this juncture 
> in the build which would cause this
> 
> :info:build dyld: Library not loaded: @rpath/libatk-bridge-2.0.0.dylib
> 
> error.  I don't see any references to GTK3 issues in my macports-users 
> archive nor in Trac, so I'm assuming it's Operator Error on my part, but 
> I don't know what I did wrong.  I did a "port clean gtk3" but I still 
> get the same error.
> 
>   - Greg
>

Re: Apple ARM binary codesign issue

[Michael Dickens]

Excellent! Thanks for the heads-up. I've downloaded this file and will get it 
installed and start testing later today. - MLD

On Tue, Sep 29, 2020, at 2:47 PM, Gary Palter wrote:
> Apple today released Xcode 12.2 beta 2 and the Release Notes state
>> Apple Clang Compiler

>> Resolved Issues

>>  * Fixed an issue that caused `strip`, `install_name_tool` and `vtool` to 
>> corrupt the ad-hoc code signatures generated by the linker for arm64 Mach-O 
>> files. (51911417)
> 
>   - Gary Palter
> Principal Software Engineer
> Clozure Associates
> Cell:  617-947-0536

Re: Apple ARM binary codesign issue

[Michael Dickens]

Let's try this again from my MP email so that it gets to lists ... sorry for 
duplicate emails!

I've finally gotten to the point of working out a hack solution.

One can -not- modify '/usr/bin' without a lot of effort. But, one can modify 
'/Applications/Xcode[-beta].app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin'
 ... and yes I know this is outside the scope of what MP does or is (likely) 
willing to do. As noted: This is a hack to prove that it works.

In 
'/Applications/Xcode[-beta].app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin'
 I move the target executables from 'foo' to 'foo_orig', then create a script 
'foo' that first calls 'foo_orig ${@}' then 'codesign' to update the signature 
on the binary. The executables in '/usr/bin' just call those in 
'/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin',
 so my script is treated as a system provided executable for 'foo'. Initial 
testing looks positive, regardless of how hacky this is.

Question: which executables am I targeting here? I think 'strip', 'lipo', and 
'install_name_tool' are the obvious ones. is that all? Any others that need 
this wrapping? - MLD

Re: Apple ARM binary codesign issue

[Michael Dickens]

I have macOS 11.0beta7 installed : check!

Compare / contrast ARM Mac versus MacBook Pro 16 : check!

I have Xcode 12.2 beta installed : check!

I've removed "/Library/Developer/CommandLineTools" : check!

I hope that Apple fixes their toolchain to work without such intervention : 
check!

Do you know that best way we can complain to Apple to fix the toolchain?

Still doesn't work for me ... those specific files are almost the only ones 
that just don't respond to codesign. I'll try reinstalling from scratch ... 
maybe ports built with Xcode 12.0 don't entirely work with those built using 
12.2beta? H 

Thx! - MLD

On Tue, Sep 22, 2020, at 2:58 PM, Ryan Schmidt wrote:
> 
> 
> On Sep 22, 2020, at 13:29, Michael Dickens wrote:
> 
> > % codesign -v - --ignore-resources 
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> > invalid signature (code or signature have been modified)
> > % sudo codesign -s - 
> > --preserve-metadata=identifier,entitlements,flags,runtime -f 
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> > replacing existing signature
> > /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> > the codesign_allocate helper tool cannot be found or used
> > % which codesign
> > /usr/bin/codesign
> > % which codesign_allocate
> > /usr/bin/codesign_allocate
> > 
> 
> You need Xcode 12.2 beta, which you probably have, but also make sure 
> that you don't have old command line tools installed. I don't think the 
> Xcode 12.0 beta command line tools are compatible, and there isn't an 
> Xcode 12.2 beta command line tools yet. Delete 
> /Library/Developer/CommandLineTools.
> 
> 
> % codesign -v - 
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> invalid signature (code or signature have been modified)
> In architecture: arm64
> % codesign -s - 
> --preserve-metadata=identifier,entitlements,flags,runtime -f 
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> replacing existing signature
> ...
> % codesign -v - 
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> valid on disk
> mp/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
> satisfies its Designated Requirement
> %
> 
> 
> > Mentioned as possible fixes were: (1) inserting MP strip and 
> > install_name_tool wrappers that sign the binary if the signature is broken; 
> > or (2) a new step in destroot_finish .
> 
> I hope that Apple fixes their toolchain to work without such intervention.
> 
>

Apple ARM binary codesign issue

[Michael Dickens]

There has been some discussion about the recent change Apple made for macOS 
11.0beta7 for ARM Mac only (-not- Intel Mac at this time); we in MP-land had 
some on this PR < https://github.com/macports/macports-ports/pull/8328 >. As 
pointed out, a better venue for discussion would be these lists.

The brief summary is that Apple is instituting code signing for all binaries 
during linking as noted here < 
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-universal-apps-beta-release-notes#Updates-in-macOS-Big-Sur-11-Universal-Apps-Beta-7
 >. The signing is as-hoc and done automatically; it is invalidated if one 
modifies the binary in any way ... for example using "strip", or 
"install_name_tool" to change the name of a required library, or even the 
self-ID name.

Many MacPorts installs use various post-linking means to tweak the resulting 
binary, and hence these are not currently usable under macOS 11.0beta7 or more 
recent on ARM Mac only; again: this change is NOT for Intel Mac -- at least not 
at this time.

One can test whether the signing is valid via the command: "codesign -v FILE" ; 
according to Apple one should use "codesign -v - --ignore-resources FILE" 
to be more verbose as well as look at just the non-resource binary. Both work 
in my testing.

In my initial testing, some of the binaries can be made to work via the command 
"[sudo] codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime 
-f FILE" ... but, not all! For example:
{{{
% codesign -v - --ignore-resources 
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
invalid signature (code or signature have been modified)
% sudo codesign -s - --preserve-metadata=identifier,entitlements,flags,runtime 
-f /opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: 
replacing existing signature
/opt/local/Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8: the 
codesign_allocate helper tool cannot be found or used
% which codesign
/usr/bin/codesign
% which codesign_allocate
/usr/bin/codesign_allocate
}}}

So in this case, "codesign_allocate" cannot be used for some non-obvious reason 
(as it clearly is in the PATH and works for some other codesign efforts). The 
same holds true for some of the Python libraries and some of the primary 
executables -- but, not all!

Mentioned as possible fixes were: (1) inserting MP strip and install_name_tool 
wrappers that sign the binary if the signature is broken; or (2) a new step in 
destroot_finish .

Let's pick up the discussion here, and try to work out a fix in short order. 
For those of us trying to do anything within MacPorts using ARM Mac, this new 
feature is causing significant issues & needs to be dealt with so that we can 
get back to real work instead of fighting macOS::codesign .

Cheers! - MLD

Re: Failed to build graphviz: command execution failed

[Michael Newman via macports-users]

> On Sep 4, 2020, at 07:27, Ryan Schmidt  wrote:
> 
> It's especially non-straightforward when Apple breaks things, like removing 
> the receipt of the command line tools periodically, which is what that 
> problem hotlist entry is about.

OK, now I understand why what I tried didn't work and why you need the little 
"touch" trick.

Thanks.

Re: Failed to build graphviz: command execution failed

[Michael Newman via macports-users]

> On Sep 4, 2020, at 05:51, Ryan Schmidt  wrote:
> 
>> Warning: cltversion: For a possible fix, please see: 
>> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt 
>> 
> 
> Follow the instructions at that URL.

Thank you. Graphviz built after updating the command line tools.

I'm still not sure why this didn't work:

MrMuscle:~ mnewman$ xcode-select --install
xcode-select: error: command line tools are already installed, use "Software 
Update" to install updates

But, after doing that, Software Update didn't find any updates available. 

My browser history shows that after graphviz failed to build I visited:

> https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt 
> 
But my bash history doesn't go back far enough to show me what went wrong the 
first time I tried that.

Thanks again for your help. As you may have discovered, I need primary school 
level instructions.

Mike

Re: Failed to build graphviz: command execution failed

[Michael Newman via macports-users]

> On Sep 3, 2020, at 22:01, Ryan Schmidt  wrote:
> 
> There have been a few other reports lately of graphviz build failures for 
> other reasons; if you're experiencing a graphviz build failure, see if one of 
> them applies.

I spent some time searching around, but all I found were other instance of 
graphviz related tickets, the details of which are beyond my ability to 
comprehend.

When graphviz builds, I get this warning:

Warning: cltversion: The Command Line Tools are installed, but MacPorts cannot 
determine the version.
Warning: cltversion: For a possible fix, please see: 
https://trac.macports.org/wiki/ProblemHotlist#reinstall-clt

So, I run this:

MrMuscle:~ mnewman$ xcode-select --install
xcode-select: error: command line tools are already installed, use "Software 
Update" to install updates

But, that doesn't fix the "MacPorts cannot determine the version" warning. 

Xcode is at Version 11.7 (11E801a)

The details:

--->  Computing dependencies for graphviz
--->  Fetching archive for graphviz
--->  Attempting to fetch 
graphviz-2.40.1_3+pangocairo+x11.darwin_19.x86_64.tbz2 from 
http://jog.id.packages.macports.org/macports/packages/graphviz
--->  Attempting to fetch 
graphviz-2.40.1_3+pangocairo+x11.darwin_19.x86_64.tbz2 from 
https://kmq.jp.packages.macports.org/graphviz
--->  Attempting to fetch 
graphviz-2.40.1_3+pangocairo+x11.darwin_19.x86_64.tbz2 from 
http://nue.de.packages.macports.org/graphviz
--->  Building graphviz
Error: Failed to build graphviz: command execution failed
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_graphviz/graphviz/main.log
 for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

The log file referred to is rather large (almost 1MB) and incomprehensible to 
me.

I don't know how to proceed from here.

Failed to build graphviz: command execution failed

[Michael Newman via macports-users]

I realize that there is a ticket on this (57137) that has been open for quite 
some time.

However, this is the first time I've seen this error. What concerns me is this:

MrMuscle:~ mnewman$ port rdependents graphviz
The following ports are dependent on graphviz:
  vala
gssdp
  gupnp
gupnp-igd
  libnice
gstreamer1-gst-plugins-bad
libproxy
  glib-networking
libsoup
  gstreamer1-gst-plugins-good
  neon
librsvg
  ffmpeg
chromaprint

I use both gstreamer and ffmpeg regularly.

Does this mean that these may stop working until the graphviz problem is fixed?

If so, what can I do?

Mike Newman
Korat, Thailand

Port that converts heic/heif?

[Michael]

What port will convert heic/heif to png or mpg?

I see (port search heif) that there is a library, but I could not find any 
program that used it

---
This message was composed with the aid of a laptop cat, and no mouse

Re: Is It Safe To Use reclaim?

[Michael Newman via macports-users]

Thanks to all for the clearly written suggestions.

At this point I don't understand most of this well enough to have any 
confidence that I won't mess things up worse than they already are.

I'm not much concerned about storage, so I think my best course of action here 
is to disable the reclaim reminder until I have a better grasp of MacPorts. 
(Which, given my age and cognitive ability is probably never.)

Thanks again for your time.

Re: Is It Safe To Use reclaim?

[Michael Newman via macports-users]

> On May 3, 2020, at 21:28, Ryan Schmidt  wrote:
> 
> Look at the output of "port installed unrequested". If you see any port in 
> that list that you actually do want, indicate that by running "sudo port 
> setrequested thePortName".

This is easier said than done.

The output of port installed unrequested has 461 items; most of which I don't 
recognize. Lynx is there and I know I want that. But the first port listed is 
a52dec. I don't know what that is, or what it does or whether or not I want it. 
I also see atk, automake, bison, harfbuzz, and many others which mean nothing 
to me.

Sure, I can do some research to figure out what each of these does, but then I 
will still have no idea whether or not I want them. Did I request some in the 
distant past? Am I still using them? No idea.

It seems to be a very daunting task. 

Is It Safe To Use reclaim?

[Michael Newman via macports-users]

Late last year I ran reclaim for the first time. It was somewhat of a disaster 
because it removed ports that I actually wanted and I ended up having to 
completely reinstall MacPorts.

Since then I have been afraid to use it again.

As far as I can tell there is no way for me to be sure that ports that I have 
actually requested have been so flagged:

MrMuscle:~ mnewman$ port installed | grep lynx
  lynx @2.8.9rel.1_1+ssl (active)
MrMuscle:~ mnewman$ port installed requested | grep lynx
MrMuscle:~ mnewman$ 

I know that I can use setrequested to flag a port, but how can I know on which 
ports I need to do that?

The only way I can think of is to manually go through the list of installed 
ports, try to recognize the ones I've requested, check to see if they are so 
flagged and, if not, manually flag them.

Is there an easier way?

Mike Newman
Korat, thailand

Re: swig4 vs swig

[Michael Dickens]

Hi Leo - We just merged in changes that swap which SWIG provides "bin/swig" ... 
so, if you update your ports, then SWIG4 will be providing this binary. 
Hopefully that addresses your issue! - MLD

On Thu, Apr 2, 2020, at 12:57 PM, Singer, Leo P. (GSFC-6610) wrote:
> Hi,
> 
> I noticed that the "swig" port installs its SWIG binary as "swig4". 
> Unfortunately, I am trying to build another project that requires SWIG 
> 4, and by default it looks for the binary "swig." There is a comment in 
> the Portfile:
> 
>   # temporary workaround until we are sure all ports build with SWIG 4.
> 
> This has been there since August. What is blocking an outright upgrade 
> to SWIG 4 in MacPorts?
> 
> Thanks,
> Leo

Re: EXSi

[Michael]

> Did you try a current version of macOS on top of ESXi? I'd be curious if 
> anyone has tested this setup and how is the performance.

What is ESXi?

---
Entertaining minecraft videos
http://YouTube.com/keybounce

Filing suit against legal abusers

[Michael]

On 2020-02-15, at 11:28 AM, Jeffrey Walton  wrote:

>  Checkout Walton vs Network
> Solutions filed in Montgomery County, MD.

PLEASE, tell us more.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

Re: Dependency untangling riddle

[Michael]

On 2020-02-05, at 11:31 AM, Vincent  wrote:
> 
> In my case, I delay the bump somewhat because I know most of my ports depend 
> not only on the language itself, but also on various  py-xxx librairies, the 
> update of which often comes pretty late after the new Python version has been 
> released.
> 
> Cheers and apologies again,
> Vincent

Is there a concept of "python-stable" versus "python-newest" like there is the 
-devel versions?

Re: Git question

[Michael]

On 2020-01-09, at 2:33 PM, Steven Smith  wrote:

> Me too. We’re discussing MacPorts-relevant git commands in 
> https://github.com/macports/macports-ports/pull/6106 .
> 
> Easiest, most destructive to local:
> 
> # save all local files changed outside the git repo
> 
> git fetch --all
> git reset --hard upstream/master
> 
> # restore all local files

I'm sorry, I just have to follow up with this xkcd ...

https://xkcd.com/1597/

Re: /usr/local/bin/lynx: Bad CPU type in executable

[Michael Newman via macports-users]

On Dec 23, 2019, at 21:06, Ryan Schmidt  wrote:
> 
> As far as I know, yes it does, by default, which is why, if you install them 
> to their default locations, you should only use one package manager and 
> uninstall the other to prevent conflicts.

I supposed that in an ideal world where a single package manager had all 
available packages and where broken packages were fixed quickly, that might 
work.

Unfortunately, this is not the case.

I have been using ffmpeg from MacPorts daily for several years. It broke with 
the release of Catalina. A ticket has been filed (59750). But, I can’t wait for 
it to get fixed. I need it every day. The only alternative I could find was 
avconv, which MacPorts doesn’t have. I don’t know how long it will be before 
ffmpeg works again.

However, I do have some experience. I used to use sunwait. It broke. I filed a 
ticket (51700). It took two years before sunwait was fixed. In the meantime, I 
had to find an alternative.

I’m not trying to be critical here. I understand the situation. This is all 
done by volunteers who have way more smarts and ability than I have. 

The reality is that people are going to use more than one package manager if 
the need arises. 

Re: /usr/local/bin/lynx: Bad CPU type in executable

[Michael Newman via macports-users]

On Dec 22, 2019, at 22:04, Ryan Schmidt  wrote:

> Since reclaim prints a list of the ports it will remove, it seems like it's 
> up to you to verify that there isn't anything on the list that you want to 
> keep before confirming the action, and it should not be surprising or scary 
> to you that MacPorts does then remove the ports it said it would remove if 
> you allow it to do 
> so.

No, you’re absolutely right. The scary thing is how stupid and sloppy I seem to 
be.

On the other hand, the list of ports to be removed was huge. How am I to know 
if it’s OK to remove something like popt?

> And more generally, remove anything you have in /usr/local.

Isn’t that where Homebrew installs its stuff? I prefer to use MacPorts, but 
sometimes I need something that doesn’t have a port, like avconv, growlnotify 
and others.

Re: /usr/local/bin/lynx: Bad CPU type in executable

[Michael Newman via macports-users]

More of the story.

When I got up this morning I found that a couple of scripts that I run 
overnight had failed with error 127. It seems that the scripts couldn’t find 
curl. So I checked, and sure enough, curl was missing. No worries, I can 
reinstall it.

And then I wonder, what else is missing? I try: 

  port list installed 

and find that there are only two ports: lynx which I installed yesterday and 
curl which I had just installed.

What happened? Well, just before installing lynx I did a selfupdate and 
upgrade. At the end of the upgrade I was invited to do a reclaim. So, I did. 
Now, admittedly, reclaim presented me with a huge long list of stuff it was 
going to remove.  Whenever I look at all the ports on my machine I only 
recognize a handful; most are things I know nothing about and never requested, 
they’re just stuff that the ports I want depend on. Fair enough. 

However, it would be nice if reclaim warned you that it was working with an 
empty or near empty requested file.

I’m sure that as part of the Catalina migration I did:

  sudo port unsetrequested installed
  xargs sudo port setrequested < requested.txt

Either I forgot, or it didn’t work. In any event, apparently every installed 
port was removed.

Fortunately, I still had the myports.txt file, so I was able to use:

  sudo ./restore_ports.tcl myports.txt

And get everything back.

I find it a little scary that a few simple mistakes can cause such havoc.

Mike Newman
Korat, Thailand

Re: /usr/local/bin/lynx: Bad CPU type in executable

[Michael Newman via macports-users]

On Dec 21, 2019, at 19:00, Bill Cole wrote:
> 
> Is it possible that your /usr/local/bin/lynx is a relic of some ancient 
> time and a different machine?

Yes. Here’s the whole story:

I wanted to use the lynx trace facility and had forgotten that sometime in the 
distant past I had installed lynx. So, I installed it via MacPorts. But, when I 
first ran it I got the Bad CPU error.

That seemed wrong since I had just installed it so I tried both locate lynx and 
which -a lynx. But both of those only found: /usr/local/bin/lynx.

This was even more confusing.

As suggested, I deleted the old version of lynx and now both which and locate 
find the MacPorts version.

/usr/local/bin/lynx: Bad CPU type in executable

[Michael Newman via macports-users]

Sorry. I used the wrong version of Lynx….

MacPorts Version: 2.6.2
macOS 10.15.2

I installed lynx today and received the error message:

/usr/local/bin/lynx: Bad CPU type in executable

Is there anything I can do about this?

MacPorts is up to date:

MrMuscle:~ mnewman$ sudo port upgrade outdated
Nothing to upgrade.
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

/usr/local/bin/lynx: Bad CPU type in executable

[Michael Newman via macports-users]

MacPorts Version: 2.6.2
macOS 10.15.2

I installed lynx today and received the error message:

/usr/local/bin/lynx: Bad CPU type in executable

Is there anything I can do about this?

MacPorts is up to date:

MrMuscle:~ mnewman$ sudo port upgrade outdated
Nothing to upgrade.
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

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

[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

[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

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 

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

Sharing free space?

[Michael]

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

I'd like to know how to get two volumes to share free space if they are on the 
same physical disk.

Heck, even with 10.9-10.12's logical volume groups, the same question.

If this is something new in the "We'll force your root disk to be repartitioned 
because we're now making root read only" system, then it's a "don't care, 
thanks anyways" issue.


---
Entertaining minecraft videos
http://YouTube.com/keybounce

Re: mysql57, boost and postgresql84

[Michael Newman via macports-users]

I don’t know if it helps at all, but on October 24th I did the first steps of 
MacPorts migration in anticipation of installing Catalina. I never did install 
Catalina, but I saved the myports.txt and requested.txt files. They are here:

https://pastebin.com/cxM85Dq6 

https://pastebin.com/8sJafzKa 

This is before I did the reclaim that removed clamav.

> On Nov 9, 2019, at 09:40, Ryan Schmidt  wrote:
> 
> 
> 
> On Nov 8, 2019, at 20:31, Chris Jones  wrote:
> 
>> On 9 Nov 2019, at 1:39 am, Ryan Schmidt wrote:
>> 
>>> If you ran `sudo port install clamav`, and it was not already installed, 
>>> MacPorts should have marked it as requested. If clamav was automatically 
>>> installed as a dependency of something else, then it would not have been 
>>> marked requested.
>> 
>> That sounds like something we should fix to me. Is it not reasonable to 
>> expect the port in this case, even if it was previously installed as a 
>> dependency, to still be marked as requested in this case, as that is what 
>> the user did by asking for it to be installed. The fact it already was 
>> shouldn’t matter in terms of marking it as requested ?
> 
> If you mean that running `sudo port install` on a port that is already 
> installed should mark it as requested, then that's 
> https://trac.macports.org/ticket/55085.
> 

Re: mysql57, boost and postgresql84

[Michael Newman via macports-users]

> On Nov 7, 2019, at 06:34, Ryan Schmidt  > wrote:
> 
> If `port installed requested` shows things that you don't actually want, tell 
> MacPorts by marking them as not requested:
> 
> sudo port unsetrequested portname1 portname2 ...
> 
> Then `sudo port reclaim` will be able to uninstall them, if they're not 
> needed for anything else you've installed. Reclaim won't uninstall things it 
> thinks you want.
This set a little trap for me. For some reason, clamav, which I did request, 
was not shown as requested. So, when I ran reclaim, it was removed. I was 
puzzled at first when freshclam started to fail. I’ve reinstalled clamav now 
and all is well. Is there some reason why clamav would not be flagged as 
requested?

Re: mysql57, boost and postgresql84

[Michael Newman via macports-users]

Thank you. I’m slowly (very slowly) beginning to pull all this together.

> On Nov 7, 2019, at 06:34, Ryan Schmidt  wrote:
> 
> If `port installed requested` shows things that you don't actually want, tell 
> MacPorts by marking them as not requested:
> 
> sudo port unsetrequested portname1 portname2 ...
> 
> Then `sudo port reclaim` will be able to uninstall them, if they're not 
> needed for anything else you've installed. Reclaim won't uninstall things it 
> thinks you want.

Re: mysql57, boost and postgresql84

[Michael Newman via macports-users]

On Nov 6, 2019, at 19:00, Chris Jones wrote:

> You could also try rerunning
> 
>> sudo port reclaim
> 
> which does a number of tasks aimed at removing stuff you do not need.

Thank you for that. It returned a massive list of unused and unneeded ports 
including this:

> Found 1156 files (total 4.80 GiB) that are no longer needed and can be 
> deleted.
> [l]ist/[d]elete/[K]eep: d
> Deleting...
> This appears to be the first time you have run 'port reclaim'. Would you like 
> to be reminded to run it every two weeks? [Y/n]: y

I’m so good about updating and upgrading regularly. I can’t believe I missed 
this.

Still learning.

Mike

Re: mysql57, boost and postgresql84

[Michael Newman via macports-users]

I have no idea why I have postgreSQL:

MrMuscle:~ mnewman$ sudo port dependents postgresql84
postgresql84-server depends on postgresql84
MrMuscle:~ mnewman$ sudo port dependents postgresql84-server
postgresql84-server has no dependents.

I didn’t request it. I don’t use it.

When I list requested ports, there are always several that I don’t recognize, 
such as:

boost, gcc7, mysql57-server,  and nss.

But, there they are.

> On Nov 6, 2019, at 13:09, Wahlstedt Jyrki  wrote:
> 
> 
> 
>> Michael Newman via macports-users > <mailto:macports-users@lists.macports.org>> kirjoitti 6.11.2019 kello 3.39:
>> 
>> Error: Failed to configure postgresql84, consult 
> 
> Hi,
> if you need PostgreSQL, this version has been EOL’d already for many years, 
> current version is 12. Documentation for upgrade here: 
> https://www.postgresql.org/docs/current/pgupgrade.html 
> <https://www.postgresql.org/docs/current/pgupgrade.html>…
> 
> 
> !
> ! Jyrki
> 

Re: mysql57, boost and postgresql84

[Michael Newman via macports-users]

Thanks Ryan.

I have reactivated boost.

The config log is here: https://pastebin.com/VdiZHn4k 
<https://pastebin.com/VdiZHn4k>

Mike

> On Nov 6, 2019, at 12:30, Ryan Schmidt  wrote:
> 
> 
> 
> On Nov 5, 2019, at 19:39, Michael Newman wrote:
> 
>> Maybe I’m just not smart enough to play with MacPorts….
> 
> Normally things work pretty well. Sometimes you'll encounter errors. 
> Unfortunately we'll have to deal with them on a case by case basis!
> 
> 
>> This on an iMac still running Mojave.
>> 
>> This morning I did selfupdate and upgrade outdated with the following result:
>> 
>> Error: mysql57 cannot be built while boost is active.
>> Error: Please forcibly deactivate boost, e.g. by running:
>> Error:
>> Error: sudo port -f deactivate boost
>> Error:
>> Error: Then try again. You can reactivate boost again later.
>> 
>> I deactivated boost as instructed and ran upgrade outdated again.
>> 
>> This time mysql built OK, but I got:
> 
> Ok great. Don't forget to reactivate boost. (sudo port activate boost)
> 
> 
>> Error: Failed to configure postgresql84, consult 
>> /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_postgresql84/postgresql84/work/postgresql-8.4.22/config.log
>> Error: Failed to configure postgresql84: configure failure: command 
>> execution failed
>> 
>> The config.log file referred to is just under 1000 lines long. Is there 
>> anything in particular I should look for?
> 
> Please show us this file. You could file a bug report in our issue tracker 
> and attach it. Or you could upload it to a paste service (perhaps 
> https://paste.macports.org ) and send us the URL.
> 

mysql57, boost and postgresql84

[Michael Newman via macports-users]

Maybe I’m just not smart enough to play with MacPorts….

This on an iMac still running Mojave.

This morning I did selfupdate and upgrade outdated with the following result:

Error: mysql57 cannot be built while boost is active.
Error: Please forcibly deactivate boost, e.g. by running:
Error:
Error: sudo port -f deactivate boost
Error:
Error: Then try again. You can reactivate boost again later.

I deactivated boost as instructed and ran upgrade outdated again.

This time mysql built OK, but I got:

Error: Failed to configure postgresql84, consult 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_databases_postgresql84/postgresql84/work/postgresql-8.4.22/config.log
Error: Failed to configure postgresql84: configure failure: command execution 
failed

The config.log file referred to is just under 1000 lines long. Is there 
anything in particular I should look for?

Re: postgresql83-server - Further Woes

[Michael Newman via macports-users]

The only solution offered by the developer of DetectX was to tell DetectX to 
ignore changes to macports plist files. 

That seems to defeat the purpose of DetectX. 

DetectX is supposed to warn you of possible nefarious changes to your system. 
Choosing to ignore a possible problem is no solution.

> On Nov 4, 2019, at 21:29, Ryan Schmidt  wrote:
> 
> Well MacPorts isn't the program that's complaining, DetectX is. So I'd ask 
> the developer of DetectX.

Re: qt5-qt3d complains about system assimp missing

[Michael A. Leonetti]

Did exactly this for ticket #59601.

Michael A. Leonetti
As warm as green tea

On 11/4/19 3:59 PM, Ryan Schmidt wrote:

On Nov 4, 2019, at 14:25, Michael A. Leonetti wrote:


My qt5 installation keeps complaining about missing linking files so I am 
trying to reinstall and qt5-q3d complains about missing system-assimp.

Is there a variant I'm missing that I can disable?


:debug:configure 
SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk'
:info:configure Executing:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qt3d/work/qt3d-everywhere-src-5.12.5"
 && /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang -- -system-assimp
:debug:configure system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qt3d/work/qt3d-everywhere-src-5.12.5"
 && /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang -- -system-assimp
:info:configure Running configuration tests...
:info:configure Done running configuration tests.
:info:configure Configure summary:
:info:configure Qt 3D:
:info:configure   Assimp . yes
:info:configure   System Assimp .. no
:info:configure   Output Qt3D Job traces . no
:info:configure   Output Qt3D GL traces .. no
:info:configure   Use SSE2 instructions .. yes
:info:configure   Use AVX2 instructions .. no
:info:configure   Aspects:
:info:configure Render aspect  yes
:info:configure Input aspect . yes
:info:configure Logic aspect . yes
:info:configure Animation aspect . yes
:info:configure Extras aspect  yes
:info:configure Qt 3D Renderers:
:info:configure   OpenGL Renderer  yes
:info:configure Qt 3D GeometryLoaders:
:info:configure   Autodesk FBX ... no
:info:configure ERROR: Feature 'system-assimp' was enabled, but the pre-condition 
'features.assimp && libs.assimp' failed.
:info:configure Check config.log for details.
:info:configure Command failed:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qt3d/work/qt3d-everywhere-src-5.12.5"
 && /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang -- -system-assimp
:info:configure Exit code: 3

Looks like qt5-qt3d just requires assimp. Sounds like you should file a bug 
report and attach the full logs. qt5-qt3d does declare a dependency on assimp, 
so we would need to see the logs to know why qt3-qt3d thinks it's not there.

qt5-qt3d complains about system assimp missing

[Michael A. Leonetti]

I just upgraded to Catalina (so many regrets).

My qt5 installation keeps complaining about missing linking files so I 
am trying to reinstall and qt5-q3d complains about missing system-assimp.


Is there a variant I'm missing that I can disable?

:debug:configure 
SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk'
:info:configure Executing:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qt3d/work/qt3d-everywhere-src-5.12.5" 
&& /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang 
-- -system-assimp
:debug:configure system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qt3d/work/qt3d-everywhere-src-5.12.5" 
&& /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang 
-- -system-assimp

:info:configure Running configuration tests...
:info:configure Done running configuration tests.
:info:configure Configure summary:
:info:configure Qt 3D:
:info:configure   Assimp . yes
:info:configure   System Assimp .. no
:info:configure   Output Qt3D Job traces . no
:info:configure   Output Qt3D GL traces .. no
:info:configure   Use SSE2 instructions .. yes
:info:configure   Use AVX2 instructions .. no
:info:configure   Aspects:
:info:configure Render aspect  yes
:info:configure Input aspect . yes
:info:configure Logic aspect . yes
:info:configure Animation aspect . yes
:info:configure Extras aspect  yes
:info:configure Qt 3D Renderers:
:info:configure   OpenGL Renderer  yes
:info:configure Qt 3D GeometryLoaders:
:info:configure   Autodesk FBX ... no
:info:configure ERROR: Feature 'system-assimp' was enabled, but the 
pre-condition 'features.assimp && libs.assimp' failed.

:info:configure Check config.log for details.
:info:configure Command failed:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_aqua_qt5/qt5-qt3d/work/qt3d-everywhere-src-5.12.5" 
&& /opt/local/libexec/qt5/bin/qmake PREFIX=/opt/local -spec macx-clang 
-- -system-assimp

:info:configure Exit code: 3


--
Michael A. Leonetti
As warm as green tea

Re: postgresql83-server - Further Woes

[Michael Newman via macports-users]

I have a license for and use DetectX Swift.

I wrote to the developer. Phil’s full reply is below. I am a bit wary about 
simply telling DetectX to ignore this. Something is going on and I want to know 
what it is.

I’ve written Phil back to let him know what I learned from this list.

(I am grateful for the help I receive here.)

>> Hi Mike
>> 
>> 
>> If DetectX is throwing that alert, double-check the following locations to 
>> see if the file exists:
>> 
>> ~/Library/LaunchAgents
>> /Library/LaunchAgents
>> /Library/LaunchDaemons
>> 
>> If it doesn't appear in one of those three locations, then it's likely that 
>> macports is writing the file there as a temporary item and then deleting it.
>> 
>> There's a couple of options for stopping this behaviour.
>> 
>> First, in DetectX Preferences, you can turn off the Folder Observer function 
>> in the Obsever tab.
>> 
>> Alternatively, in the same preferences tab, you can leave Folder Observer 
>> and add "org.macports" to the "Ignore Keywords" list.
>> 
>> [image removed]
>> 
>> Let me know if you need any further help.
>> 
>> 
>> Best
>> 
>> 
>> Phil
>> @sqwarq

> On Nov 4, 2019, at 06:27, Al Varnell  wrote:
> 
> Recommend you contact the Developer at <https://sqwarq.com/contact/ 
> <https://sqwarq.com/contact/>>. Phil has been a colleague of mine for several 
> years and very responsive. Operates out of Australia.
> 
> You should be aware that if you are actually using the older DetectX rather 
> thanDetectX Swift, it's not going to be supported beyond next May. He posted 
> the following to his Slack community late last week:
> 
> 1. The older versions of DetectX (not DetectX Swift) are no longer being 
> offered for download on the Sqwarq site.
> 2. The older versions will continue to receive maintenance updates and search 
> definition updates until June 1st, 2020.
> 3. It is no longer possible to buy registration keys for the older versions 
> of DetectX.
> 
> -Al-
> 
>> On Nov 3, 2019, at 13:33, Michael Newman > <mailto:mgnew...@mac.com>> wrote:
>> 
>> Thank you.
>> 
>> I asked the developers of DetectX and this is what they said:
>> 
>>> If DetectX is throwing that alert, double-check the following locations to 
>>> see if the file exists:
>>> 
>>> ~/Library/LaunchAgents
>>> /Library/LaunchAgents
>>> /Library/LaunchDaemons
>>> 
>>> If it doesn't appear in one of those three locations, then it's likely that 
>>> macports is writing the file there as a temporary item and then deleting it.
>> 
>> The plist file definitely does not exist:
>> 
>> MrMuscle:Volumes mnewman$ sudo launchctl list | grep 'org\.macports\.'
>> Password:
>> 81   0   org.macports.dnsmasq
>> -0   org.macports.clamd
>> 89   0   org.macports.mysql57-server
>> 
>> So, I find myself stuck in the middle. Is it a DetectX problem or a MacPorts 
>> problem?
>> 
>> I don’t know.
>> 
>>> On Nov 3, 2019, at 21:38, Ryan Schmidt >> <mailto:ryandes...@macports.org>> wrote:
>>> 
>>> 
>>> 
>>> On Nov 3, 2019, at 04:46, Michael Newman wrote:
>>> 
>>>> I have uninstalled the port, but DetectX keeps telling me that the plist 
>>>> has been changed. If it only happened once when I still had the port 
>>>> installed I’d say, yeah, problem solved. But when the plist keeps getting 
>>>> changed after the port has been uninstalled I have to wonder what’s 
>>>> happening.
>>>> 
>>>> DetectX doesn’t tell me where the plist is located or what process changed 
>>>> it; just that it has been changed. Over and over again.
>>>> 
>>>> Perhaps this is a bug in DetectX, but I have no way of knowing that.
>>> 
>>> You could ask the developers of DetectX. If it's complaining to you about a 
>>> file that doesn't appear to be on your disk, I don't know what else to 
>>> suggest, except:
>>> 
>>> Maybe back when you had postgresql83-server installed, you loaded the 
>>> plist, and now that it's gone, the system is trying to load it every 10 
>>> seconds, and maybe DetectX is noticing that. You could check your Console 
>>> to see if there are any mentions of issues with MacPorts launchd plists.
>>> 
>>> You can list all the MacPorts launchd plists you've loaded with:
>>> 
>>> sudo launchctl list | grep 'org\.macports\.'
>>> 
>>> If you see anything there that you don't want loaded, and the plist file 
>>> still exists, you can unload it with:
>>> 
>>> sudo launchctl unload -w /Library/LaunchDaemons/org.macports.whatever.plist
>>> 
>>> If the plist is no longer on disk, you can make launchd forget about it 
>>> with:
>>> 
>>> sudo launchctl remove org.macports.whatever
>>> 
>> 
>> 
> 

Re: postgresql83-server - Further Woes

[Michael Newman via macports-users]

I have uninstalled the port, but DetectX keeps telling me that the plist has 
been changed. If it only happened once when I still had the port installed I’d 
say, yeah, problem solved. But when the plist keeps getting changed after the 
port has been uninstalled I have to wonder what’s happening.

DetectX doesn’t tell me where the plist is located or what process changed it; 
just that it has been changed. Over and over again.

Perhaps this is a bug in DetectX, but I have no way of knowing that.

> On Nov 3, 2019, at 17:28, Al Varnell  wrote:
> 
> 
> At this point, you have solved the mystery and should simply go back to work 
> and forget about it. DetectX did it's job and so have you.
> 
> -Al-

Re: postgresql83-server - Further Woes

[Michael Newman via macports-users]

Thank you.

Locate did not find this plist on the boot volume. It did find it in a Carbon 
Copy Cloner SafetyNet directory on a backup drive.

MrMuscle:home mnewman$ locate org.macports.postgresql83-server.plist
/Volumes/Clorox2/_CCC SafetyNet/2019-10-30 (October 30) 
01-00-52/Library/LaunchDaemons/org.macports.postgresql83-server.plist
/Volumes/Clorox2/_CCC SafetyNet/2019-10-30 (October 30) 
01-00-52/opt/local/etc/LaunchDaemons/org.macports.postgresql83-server/org.macports.postgresql83-server.plist

I think the first one is a symbolic link to the second.

So, I’m stuck. I can tell DetectX to ignore this, but that seems more like a 
coverup than a solution.

> On Nov 3, 2019, at 16:51, Ryan Schmidt  wrote:
> 
> MacPorts creates plists for ports that are meant to act as servers when you 
> install those ports. The plists are removed, along with all of the port's 
> other files, when the port is uninstalled.
> 
> You can use find or locate to try to determine whether a 
> org.macports.postgresql83-server.plist file still exists even after you have 
> uninstalled the port.