Re: [OT] bad disk & MacOS reinstall

[Richard L. Hamilton]

tes, that was the problem.

Whatever it does automatically to understand what type of drive it sees isn't 
very good, at least with what I've got. I'll stick to the command line tools.

> On May 18, 2024, at 02:51, Ryan Schmidt  wrote:
> 
> On May 18, 2024, at 01:46, Richard L. Hamilton wrote:
>> 
>> dyld[16578]: Symbol not found: (_gtk_plug_construct)
>>   Referenced from: '/opt/local/lib/libgtkmm-3.0.1.dylib'
>>   Expected in: '/opt/local/lib/libgtk-3.0.dylib'
>> Abort
> 
> Are you using the quartz variant? This error was mentioned before here:
> 
> https://trac.macports.org/ticket/65743 
> <https://trac.macports.org/ticket/65743>

Re: [OT] bad disk & MacOS reinstall

[Richard L. Hamilton]

Ok, I tried that driver, and it doesn't work for any external USB I have.

An external Thunderbolt drive should just work, no driver for SMART support 
needed. My LaCie did, anyway - on the Thunderbolt interface, using Apple's 
Thunderbolt 2 to 3 adapter. Though that drive had a USB interface too, SMART 
support did not work on there.
https://www.smartmontools.org/wiki/Supported_USB-Devices 
<https://www.smartmontools.org/wiki/Supported_USB-Devices> should list which 
drives have the required SCSI/ATA translation support, i.e. may work.

gsmartcontrol crashed on me with

dyld[16578]: Symbol not found: (_gtk_plug_construct)
  Referenced from: '/opt/local/lib/libgtkmm-3.0.1.dylib'
  Expected in: '/opt/local/lib/libgtk-3.0.dylib'
Abort


(this was on Monterey with ports up to date)

but for supported devices, smartctl from the command line works fine.


> On May 17, 2024, at 22:32, Richard L. Hamilton  wrote:
> 
> The port smartmontools includes the command line tool. The port gsmartcontrol 
> provides a GUI on top of that, if you want (I've never tried the latter).
> 
> It won't work on USB drives without a kernel driver (not available in 
> MacPorts).
> 
> https://binaryfruit.com/drivedx/usb-drive-support 
> <https://binaryfruit.com/drivedx/usb-drive-support> may have links and 
> instructions (that site is for a paid product but the kernel driver is open 
> source). I haven't tried that, and in particular don't have High Sierra to 
> try it on.
> 
> 
>> On May 17, 2024, at 18:57, Riccardo Mottola via macports-users 
>> > <mailto:macports-users@lists.macports.org>> wrote:
>> 
>> Hi,
>> 
>> Horst Simon wrote:
>>> I had todo a re-install on my 2010 MacBook Pro with High Sierra from 
>>> scratch, my copy of High sierra I had was corrupted and caused my all kind 
>>> of grief. I finally downloaded a new copy on my iMac using the command line
>> Got a new disk.
>> 
>> Using recovery partition I tried to dump/restore the partiton... but half 
>> during the process I got a disk error and the process aborted. Proof that it 
>> is gone.
>> 
>> at the end, I changed hard disk and had to reinstall. Now salvaging data.
>> I will reinstall MacPorts from scratch. Safer... and also a "test" like 
>> being a new user.
>> 
>> I still am a bit disappointed by SMART.
>> 
>> Does Macports have a tool to get SMART details? On linux  there is one  
>> quite comprehensive!
>> 
>> Riccardo
>> 
> 

Re: [OT] bad disk & MacOS reinstall

[Richard L. Hamilton]

The port smartmontools includes the command line tool. The port gsmartcontrol 
provides a GUI on top of that, if you want (I've never tried the latter).

It won't work on USB drives without a kernel driver (not available in MacPorts).

https://binaryfruit.com/drivedx/usb-drive-support 
 may have links and 
instructions (that site is for a paid product but the kernel driver is open 
source). I haven't tried that, and in particular don't have High Sierra to try 
it on.


> On May 17, 2024, at 18:57, Riccardo Mottola via macports-users 
>  wrote:
> 
> Hi,
> 
> Horst Simon wrote:
>> I had todo a re-install on my 2010 MacBook Pro with High Sierra from 
>> scratch, my copy of High sierra I had was corrupted and caused my all kind 
>> of grief. I finally downloaded a new copy on my iMac using the command line
> Got a new disk.
> 
> Using recovery partition I tried to dump/restore the partiton... but half 
> during the process I got a disk error and the process aborted. Proof that it 
> is gone.
> 
> at the end, I changed hard disk and had to reinstall. Now salvaging data.
> I will reinstall MacPorts from scratch. Safer... and also a "test" like being 
> a new user.
> 
> I still am a bit disappointed by SMART.
> 
> Does Macports have a tool to get SMART details? On linux  there is one  quite 
> comprehensive!
> 
> Riccardo
> 

Re: Lilypond documentation (info+man) installation?

[Richard L. Hamilton]

I'd say build it with +docs, but that failed for me:

:info:build Making Documentation/out/lilypond-contributor.info < texi
:info:build bibtex: Not writing to 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond/work/.tmp/tmpy0vuau0_/bib2texi-tmp.blg
 (openout_any = p; no  extended check).
:info:build bibtex exited with return code 1.  Output:
:info:build I couldn't open file name 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond/work/.tmp/tmpy0vuau0_/bib2texi-tmp.blg'
:info:build bibtex: Not writing to 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond/work/.tmp/tmpko1qlc_h/bib2texi-tmp.blg
 (openout_any = p; no  extended check).
:info:build bibtex exited with return code 1.  Output:
:info:build I couldn't open file name 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_textproc_lilypond/lilypond/work/.tmp/tmpko1qlc_h/bib2texi-tmp.blg'
:info:build Making Documentation/out/en/web.texi (sed)
:info:build Making Documentation/out/lilypond-web.info < texi
:info:build Making Documentation/out/en/learning.texi < tely
:info:build Making Documentation/out/en/usage.texi < tely
:info:build Making Documentation/out/en/snippets.texi < tely
:info:build lilypond-book.py: error: file not found: colorado.itexi
:info:build gnumake[1]: *** [out/en/essay.texi] Error 1

Unless I have some peculiar situation, it looks like the docs part doesn't 
work. Maybe check for a ticket, or file one if there isn't already one for 
lilypond +docs.

> On Apr 19, 2024, at 23:41, Kenneth Wolcott  wrote:
> 
> Hi;
> 
>  I've been using Lilypond via MacPorts for some while now.
> 
>  I've been using Lilypond documentation from the Lilypond website in
> html form (sometimes from pdf).
> 
>  What I don't have is the documentation from MacPorts Lilypond in the
> info and/or man format.
> 
> man lilypond
> No manual entry for lilypond
> 
> info lilypond
> info: No menu item 'lilypond' in node '(dir)Top'
> 
> echo $MANPATH
> /opt/local/share/man:/opt/local/share/man:
> 
> echo $INFOPATH
> /opt/local/share/info
> 
>  Is this something that I have to do manually to get access to:
> 1. modify settings in my profile?
> and/or
> 2. Actually generate the documentation?
> 
> 3. Perhaps the Lilypond documentation is just not available via MacPorts...?
> 
> Thanks,
> Ken Wolcott
> 

Re: what app on a Mac reads/views ppm files?

[Richard L. Hamilton]

Preview seems to display them ok.

If you want to edit them, I suspect GIMP can do that; if course, you'd have to 
install it.

> On Apr 16, 2024, at 22:44, Kenneth Wolcott  wrote:
> 
> Hi;
> 
>  what app on a Mac reads/views ppm files?
> 
>  I've been looking at some code located on Rosetta Code that involves
> ppm files... https://rosettacode.org/wiki/Bitmap/Read_a_PPM_file
> 
> Thanks,
> Ken Wolcott
> 

Re: force rebuild a port

[Richard L. Hamilton]

My harfbuzz (on Monterey) was outdated. So I did this:

port -v upgrade harfbuzz
--->  Computing dependencies for harfbuzz.
--->  Fetching archive for harfbuzz
--->  harfbuzz-8.4.0_0.darwin_21.x86_64.tbz2 doesn't seem to exist in 
/opt/local/var/macports/incoming/verified
--->  Attempting to fetch harfbuzz-8.4.0_0.darwin_21.x86_64.tbz2 from 
https://packages.macports.org/harfbuzz
[...]

The -v  generates relatively verbose (thus the "v")  messages. It can be 
combined with other options, and goes after "port" and before a command like 
"upgrade".

Note the name of the file it downloaded, which includes an architecture. This 
was an archive of precompiled port, already successfully built on the build 
servers. So of course it was very fast to install, no compiling needed, just 
deleting, unarchiving, copying files around, etc.

Not everything can be precompiled like that; for some things, incompatible 
licenses prevent distributing binaries (ffmpeg with the +nonfree option which 
gives more codecs, is like that); and a few ports may try to do processor model 
specific optimizations; maybe there are other reasons. Ports are also only 
pre-built for default variants; if you request different variants or have 
different default variants configured, there won't be binaries available. 
Binary builds sometimes fail on the build servers, and are not always equally 
available for all macOS versions. (IMO, build failures on the build servers 
ought to automatically generate tickets; that might mean more build problems 
would be fixed before users saw them; but maybe there's reasons that doesn't 
happen.)

The global option (goes after "port", like -v) "-b" will only install or 
upgrade if binaries are available. The global option "-s" will install from 
source even if they are available.

A URL like https://ports.macports.org/port/harfbuzz/builds/ 
<https://ports.macports.org/port/harfbuzz/builds/>

in your browser (but put in the port name you want in place of harfbuzz) will 
show what if anything is pre-built for that port. Other views are available, 
but don't ask me if there's one that shows everything pre-built for a specific 
macOS version; if there is one, I haven't found it. I'm just another user, not 
a maintainer, and not familiar with everything; I knew some of these things 
were possible, but had to dig a bit to be able to describe them.

> On Apr 5, 2024, at 12:36, Riccardo Mottola  wrote:
> 
> Hi Richard,
> 
> last week I did a test and it worked, but it was not what I needed. Probably 
> it was a port already in need to upgrade.
> I have a system now where all ports are up-to-date (as of "port outdated").
> 
> If I issue e.g.
> 
> port -n upgrade --force --no-rev-upgrade gtk2
> 
> 
> It takes it time to recompile gtk2... I actually see "Building gtk2" [* * *]
> 
> If I do
> 
> port -n upgrade --force --no-rev-upgrade harfbuzz
> 
> 
> it completes in a matter of seconds... and the ol' MacBook isn't that fast :)
> 
> I see cleaning, uninstalling, cleaning, installing activating, cleaning... 
> but never configure/building!
> Why?
> 
> Regards,
> Riccardo
> 
> Richard L. Hamilton wrote:
>> To explain:
>> 
>> -n prevents rebuilding ports that the ports being upgraded (works with 
>> install too I suppose, but there should be no need for that) depend on; it 
>> may cause failure if they're not already installed and up-to-date
>> 
>> --force forces upgrading even of a port that's current; but without the -n, 
>> that would apply to everything it depends on too, which is slow and might 
>> cause more problems (esp. if there are issues with any of the build tools 
>> used)
>> 
>> --no-rev-upgrade because while the check for broken ports is usually good, 
>> it might get in the way in this sort of situation; and because one might be 
>> repeating the command one port at a time for more than one port (separate 
>> commands so it tries them all even if one fails), and since the check is a 
>> bit slow, that saves time
>> 
>> This is rather far down the list of what one should try, because normally -n 
>> is not a good idea (although it can make sense to limit --force), and 
>> because ideally one would just do "port upgrade" and let it sort out what 
>> needs doing. But clearly it helps sometimes when things aren't right and you 
>> don't want to do more than necessary.
> 

Re: force rebuild a port

[Richard L. Hamilton]

To explain:

-n prevents rebuilding ports that the ports being upgraded (works with install 
too I suppose, but there should be no need for that) depend on; it may cause 
failure if they're not already installed and up-to-date

--force forces upgrading even of a port that's current; but without the -n, 
that would apply to everything it depends on too, which is slow and might cause 
more problems (esp. if there are issues with any of the build tools used)

--no-rev-upgrade because while the check for broken ports is usually good, it 
might get in the way in this sort of situation; and because one might be 
repeating the command one port at a time for more than one port (separate 
commands so it tries them all even if one fails), and since the check is a bit 
slow, that saves time

This is rather far down the list of what one should try, because normally -n is 
not a good idea (although it can make sense to limit --force), and because 
ideally one would just do "port upgrade" and let it sort out what needs doing. 
But clearly it helps sometimes when things aren't right and you don't want to 
do more than necessary.

> On Mar 27, 2024, at 11:21, Riccardo Mottola  
> wrote:
> 
> Hi Richard,
> 
> Richard L. Hamilton wrote:
>> port -n upgrade --force --no-rev-upgrade crankyport
>> 
>> It might not work if crankyport needs the latest of something it depends on 
>> and that isn't already up-to-date. But a lot of times, it does work.
> 
> this is a good one.. appears to work for stubborn libgdk, it just rebuilt
> 
> I prefer it to build/uninstall/install because upgrade preserves the
> automatic status and variants automagically.
> 
> Riccardo
> 

Re: I just wanted to upgrade my older MacPorts version

[Richard L. Hamilton]

That's strange, in that /opt/local/var should have been part of the original 
MacPorts install, too. /opt/local/var/macports is workspace for MacPorts plus 
information about what's installed; all the other subdirectories of 
/opt/local/var are for the ports to use instead of using subdirectories of 
/var, esp. if they might conflict with a similar program that comes with the OS.

So something may have been wrong before you did the install of the new pkg. 
Among other things, I'm wondering if the previous version was for an earlier 
version of MacOS, in which case problems could be expected.

port -d selfupdate

(which impiles -v and also adds debugging messages) should provide more detail 
what failed.

"port" depends on some other commands, and will use the system version if you 
don't have a MacPorts version installed. Like rsync for sure (for selfupdate) 
and curl to fetch individual files when needed. And others like tar or cpio or 
gzip (and maybe additional commands) to deal with archives  and compressed 
files, openssl to check digital signatures, etc. If any of those are missing  
or not working, that will be a problem.

Other than that, I have no idea. I've never dug deep into how it all works, 
just glanced for a couple minutes at the tcl code for the "port" command and 
the macports specific components that it uses. There are people here who know 
much more, but they probably have day jobs too, so please be patient.


> On Mar 7, 2024, at 07:30, xmar...@iqf.csic.es wrote:
> 
> Sorry for such an stupid question…
> 
> I was running an older MacPorts version on my High Sierra and wanted to 
> upgrade the version just installing the newest one 
> (MacPorts-2.9.1-10.13-HighSierra.pkg 
> )
>  existing for my iMac. I did it and and it was made with getting no errors or 
> warnings. 
> 
> However, after this installation I only see that there appeared a new 
> directory called /opt/local/var/, but the existing executables are still the 
> old ones (the ones existing in the old  /opt/local/bin directory. 
> 
> And when I try to run “sudo port selfupdate”  I get the following error:
> 
> --->  Updating MacPorts base sources using rsync
> Error: Error synchronizing MacPorts sources: command execution failed
> Please run `port -v selfupdate' for details.
> Error: /opt/local/bin/port: port selfupdate failed: Error synchronizing 
> MacPorts sources: command execution failed
> 
> Rerunning it with the -v option I get exactly the same error and my question 
> is:
> What can I do to have the newest MacPorts binaries being upgraded?
> 
> Any help would be kindly appreciated….
> All the best,
> Martin
> 
> Dr. Martin Martinez-Ripoll
> Research Professor Emeritus
> xmar...@iqf.csic.es 
> Dept. of Crystallography & Structural Biology
> www.xtal.iqfr.csic.es
> Consejo Superior de Investigaciones Científicas
> Spanish National Research Council
> www.csic.es
> 
> 
> 
> 
> 
> 

Re: force rebuild a port

[Richard L. Hamilton]

How about

port -n upgrade --force --no-rev-upgrade crankyport

It might not work if crankyport needs the latest of something it depends on and 
that isn't already up-to-date. But a lot of times, it does work.

> On Mar 6, 2024, at 15:14, Bill Cole 
>  wrote:
> 
> On 2024-03-06 at 14:19:59 UTC-0500 (Wed, 6 Mar 2024 20:19:59 +0100)
> Riccardo Mottola via macports-users 
> is rumored to have said:
> 
>> Hi!
>> 
>> suppose I want to rebuild a port, but it has no version update.
>> 1) e.g. rev-upgrade shows it to be rebuild but "port outdated" doesn't show 
>> it.
>> 2) Or I want to rebuild it with a different compiler.
>> 
>> How can I do? "port upgrade X" will do nothing because X is not outdated.
>> "port upgrade --force X" will upgrade all dependencies, which is a little 
>> too much...
>> 
>> 1) in my case has issues because it wants to rebuild many packages and 
>> starts with one that breaks, so it never gets to the next one.
>> I tried using "-p" but apparently it is not respected for "port -p 
>> rev-upgrade" and still dies.
> 
> Try it stepwise. I believe that this will work to rebuild and install 
> 'crankyport' and nothing else, provided that none of the dependencies are out 
> of date.
> 
> port fetch crankyport
> port build crankyport
> port uninstall crankyport
> port install crankyport
> 
> But you need to understand that if a port has a dependency on another port, 
> that dependency can only be met by the current version of that port. MacPorts 
> has no mechanism to just use whatever version of a p[rt you happen to have 
> installed.
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
> 

Re: PortGroup versioning

[Richard L. Hamilton]

Can you think of anything, esp. edge cases, that might break if you didn't 
change the PortGroup version, that wouldn't break (but might require otherwise 
not strictly needed rebuilds) if you did change the version? 

Can you test any that you think of?

Are all the repositories reliably consistent/compatible?

Would anything that depends on octave be affected?

My feeling is that version numbers should be incremented for any change that 
might not be transparent (not counting build time messages that are only for 
human eyes or logging). Maybe even for changes that don't affect the result, 
simply to make the fact of the change more visible, unless incrementing the 
version number otherwise unnecessarily would risk problems of its own.


Note: I don't pretend to understand how all this works or anything about octave 
in particular, so I may be imagining problems that don't exist, or failing to 
imagine some that might. But as long as it doesn't interfere with work being 
done, I tend to think that there's no such thing as too much paranoia. :-)

I dimly recall getting a repair on a Sony Trinitron TV years ago, where the 
repair shop told me I should prefer the extra wait time and cost to obtain and 
use an OEM power transistor rather than one of nominally identical specs, 
because it was used for two different purposes at once (power and sync?) and 
driven hard, and substitutes wouldn't last long. That's one of those things 
that unless it's documented, one only would find out by hard experience. So 
documenting everything earlier may prevent problems later. In software, esp. if 
any part of building (or a human) might behave differently based on version 
number, I'd also regard version number as part of that precautionary 
documentation.

> On Feb 4, 2024, at 12:43, Marius Schamschula  wroten:
> 
> Given the recent Octave package repository move from SourceForge to GitHub 
> [1], I have updated the octave PortGroup to be able to handle the four 
> repositories that are currently in use:c
> Bitbucket, GitHub, GitLab and SourceForge.
> 
> However, this means that the old octave 1.0 setup is incompatible with the 
> current version. I.e.
> 
> Old: octave.setup package version
> 
> New: octave.setup repo author package version [tag_prefix] [tag_suffix]
> 
> This generally would be an issue, but as I’m currently the only one 
> maintaining the packages, I could switch all Portfiles to use the new syntax 
> all at once.
> 
> Or should I change the octave PortGroup to version 1.1?
> 
> Thoughts?
> 
> [1] https://trac.macports.org/ticket/69210 
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
> 

Re: Why all this GARBAGE WARE for one single app?

[Richard L. Hamilton]

Not some scam, actual dependencies, direct or indirect.

Think of it as feature creep, not by MacPorts but by the app developers. And 
also, anything they depend on, they don't have to re-invent.

But yelp is the help viewer (with capabilities beyond a text editor) that gedit 
expects to be available, and gstreamer is something yelp indirectly requires.

Some apps will ultimately require most of the GTK (or KDE) desktop 
infrastructure. Only for the 1st that requires that, subsequent ones use the 
existing copy, so building will be faster for them.

You may not like reality, but ranting is rude.

> On Nov 25, 2023, at 22:37, Mark Dm  wrote:
> 
> I am trying to install gedit on mac , installed macports, then the xcode 
> requirements rand the command to install gedit. Now about 209 minutes later I 
> am still seeing GARBAGE like GstreamerXXX and GstreamerYYY still installing . 
> THIS IS NUTS! I NEVER ASKED TO INSTALL GSTREAMER. I know there are 
> dependencies but how can gstreamer be a dependency for a text editor?
> 
> WTF now it is installing something called "yelp" 
> 
> I remember now I tried MacPorts years ago and ended up having to reformat my 
> Mac to get all the speed back after the couple of apps I installed. I regret 
> trying it again and thing it is all a bunch of GARBAGE 
> 
> Is this juist a method by which you can install garbageware onto a mac for 
> unsuspecting users?

Re: X11 and grads do not work after upgrading to Sonoma

[Richard L. Hamilton]

I don't have Sonoma, nor Ventura up at the moment, but on Monterey, /usr/X11 is 
a symlink to /var/select/X11, which is another symlink.

In my case, since I have the macosforge.org  Xquartz 
installed, it's a symlink to /opt/X11. That is of course not the macports 
version, which seems to have parts in
/opt/local/etc/X11  /opt/local/lib/X11
/opt/local/include/X11  /opt/local/share/X11
/opt/local/bin

On any of the locked down OS versions (Monterey or later at least), one 
probably can't change /usr/X11, but can probably change /var/select/X11 .

Something built without using macports would presumably tend to expect /usr/X11 
or /usr/local/X11.

> On Oct 7, 2023, at 11:29, Chris Jones  wrote:
> 
> 
> 
>> On 7 Oct 2023, at 4:25 pm, Tao Zhang  wrote:
>> 
>> Hi Chris,
>>  I am using time machine to transfer them from a Mojave Macbook pro to the 
>> present Sonoma machine.
>>  Is there a new version of X11 that can be installed into /usr/X11?
> 
> Not provided by macports, no.
> 
> I do not recommend what you are doing above as having anything in /usr/local 
> is not supported by macports
> 
>  https://trac.macports.org/wiki/FAQ#usrlocal 
> 
> 
> Remove what you are putting in these locations and instead just use the 
> macports versions
> 
> > sudo port install grads xorg-server
> 
> Chris
>> 
>>  Thanks
>>  Tao
>> 
>> 
>> On 10/7/23 9:16 AM, Chris Jones wrote:
>>> Hi,
>>> 
>>> /usr/local and /usr/X11 are not locations macports will install anything 
>>> into, so you are not using a macports provided build of grads.
>>> 
>>> You should remove everything from these locations, and then install instead 
>>> macports grads port. Also, in order to have a X11 server you should install 
>>> macports xorg-server port.
>>> 
>>> Chris
>>> 
 On 7 Oct 2023, at 4:10 pm, Tao Zhang  wrote:
 
 Hi,
 
  I have problem in X11 and grads after upgrading to  Sonoma. I am using 
 intel i9 chip.
 
  see below.
 
  Do you know how to fix it?
 
  Thanks
 
 Tao
 
 
 “XQuartz” is damaged and can’t be opened.
 
 MacBook-Pro-2018:~ 33;grads
 dyld[6709]: Library not loaded: /usr/X11/lib/libX11.6.dylib
   Referenced from:  
 /usr/local/bin/grads
   Reason: tried: '/usr/X11/lib/libX11.6.dylib' (no such file), 
 '/System/Volumes/Preboot/Cryptexes/OS/usr/X11/lib/libX11.6.dylib' (no such 
 file), '/usr/X11/lib/libX11.6.dylib' (no such file), 
 '/usr/local/lib/libX11.6.dylib' (no such file), '/usr/lib/libX11.6.dylib' 
 (no such file, not in dyld cache)
 Abort
 
>> 

Re: Timing of MacPorts Support for New macOS Versions

[Richard L. Hamilton]

I suspect that the number of people supporting MacPorts itself (not just 
specific ports) is quite small; and they're doing it in their "spare" time, at 
that.

What is typically involved in updating MacPorts itself (and any ports that have 
to be updated with it before others can be checked), and how much work is that?

Is it something others (in particular those that want it out in a particular 
timeframe) could help speed up?

Is there any macOS beta non-disclosure issue that would hinder such an effort?

Just pointing out some questions that occurred to me.

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

Re: OT maybe interesting

[Richard L. Hamilton]

Intel Macs have something called the SMC (System Management Chip, or something 
like that) which among other things, monitors all the temperature sensors and 
manages the fan speed.

There are apps (on macOS)  that can tweak the fan speed. SMCfanControl is one, 
Macs Fan Control is another; there may be others still. A decent such app will 
allow you to raise the fan speed above what the system would have picked, but 
never set it lower, to ensure that at least the builtin cooling specs are met. 
If you're going to do a parallel compile or something else that maxes your CPU, 
setting the fan speed to max before that starts will likely let you run a bit 
faster longer before getting throttled to control the temperature.

On Linux, if you google for

mac linux smc fan

you should see some alternatives. I've never run Linux on bare metal on a Mac 
(in a VM, yes), so I've never had any reason to try any of those, let alone 
recommend any particular one.

> On Jul 6, 2023, at 00:25, James  wrote:
> 
> I've been a long time macports user.
> 
> My mid 2011 iMac27 is pegged at High Sierra. I can't build recent mythtv and 
> other woes, after a fail flirt with opencore I installed linux.
> 
> I asked on the various user forums, but got only well intentioned naive 
> answers.
> 
> Is fan control done by hardware?
> 
> If so why: https://github.com/Hipuranyhou/macfand
> 
> I did a faily heavy shotcut render. At the point I chickened out cpu fan was 
> at minimum (1200 rpm) and core were at 55C
> 
> Do I need to do sw control of the fans? (Chickened out means I dialed the 
> fans to FSD and temp came down to 40C)
> 
> James
> 
> 

Re: would like to download the source of a port, but not install it (I already have installed it)

[Richard L. Hamilton]

newapple:~ root# port fetch file
--->  Fetching distfiles for file
--->  Attempting to fetch file-5.44.tar.gz from 
http://mirror.leaseweb.com/gentoo/distfiles/
newapple:~ root# find /opt/local/var/macports/distfiles -name file-5.44.tar.gz
/opt/local/var/macports/distfiles/file/file-5.44.tar.gz
newapple:~ root# ls /opt/local/var/macports/distfiles/file
file-5.41.tar.gzfile-5.44.tar.gz

Note that I had an older one left in there too; port clean doesn't get rid of 
that unless you use the --dist or --all flag.

To get an older version, you may have to go to github to get the older version 
of the Portfile, look at that, and see where it fetches from. For "file", the 
relevant Portfile (and patch files, which may exist for some ports) are in
https://github.com/macports/macports-ports/tree/master/sysutils/file 


(don't ask me how to get a particular historical version of a file from github, 
I don't use it that much)

> On Jul 1, 2023, at 16:51, Kenneth Wolcott  wrote:
> 
> Hi;
> 
>  Another very basic question that I missed the answer to in my search:
> 
> How to just download the source of a port?
> 
> I already have installed the port in question, I'd just like to
> examine the source.
> 
> All the "easy" ways to obtain the source code seem to be temporarily
> blocked by circumstances (original web site down, etc).
> 
> The specific port I'm interested in is "file".
> 
> Thanks,
> Ken Wolcott
> 

Re: best Xcode version for Mojave?

[Richard L. Hamilton]

I keep older macOS versions on VMs or old hardware for features they still had 
(Snow Leopard: Rosetta, Mojave: 32-bit support), even with other systems 
running the latest.I do NOT surf the web or use social media on the old ones!

So sometimes I have questions regarding older versions.

> On Jun 13, 2023, at 08:14, Eldrid Rensburg  wrote:
> 
> Interesting options to upgrade macOS itself on "unsupported hardware":
> 
> https://dortania.github.io/OpenCore-Legacy-Patcher/START.html 
> <https://dortania.github.io/OpenCore-Legacy-Patcher/START.html>
> https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html 
> <https://dortania.github.io/OpenCore-Legacy-Patcher/MODELS.html>
> On Tue, 13 Jun 2023, 04:26 Richard L. Hamilton,  <mailto:rlha...@smart.net>> wrote:
> "On macOS 10.14, iTerm2 @3.4.19 requires Xcode 11.0 or later but you have 
> Xcode 10.3."
> 
> 11.3.1 is the newest Xcode for Mojave.
> 
> Is there any known downside to Xcode 11.3.1 on Mojave rather than the 10.3 I 
> have on there now? Space is tight, so I'm not sure I want both.
> 
> And will I need 11.3.1 command line tools too?
> 

best Xcode version for Mojave?

[Richard L. Hamilton]

"On macOS 10.14, iTerm2 @3.4.19 requires Xcode 11.0 or later but you have Xcode 
10.3."

11.3.1 is the newest Xcode for Mojave.

Is there any known downside to Xcode 11.3.1 on Mojave rather than the 10.3 I 
have on there now? Space is tight, so I'm not sure I want both.

And will I need 11.3.1 command line tools too?

Re: gcc12 fault?

[Richard L. Hamilton]

You're right, it's zsh. And "which" seems to be builtin with zsh.

> On Jun 1, 2023, at 11:46, contextnerror ​  wrote:
> 
> I thought zsh was the new default shell?
> 
>> On Jun 1, 2023, at 8:38 AM, Richard L. Hamilton  wrote:
>> 
>> Try "type" rather than "which"; "type" is a builtin command in bash, dash, 
>> sh, and ksh. "which" is typically not a builtin. Usually they should say the 
>> same thing, but if they're not, something is odd, perhaps with your .bashrc 
>> or .profile or whatever.
>> 
>> Pretty sure dash is the default shell in Ventura (actually in Monterey 
>> too?), apparently Apple wasn't thrilled with the bash license.
>> 
>> Nothing else seems obvious, and since I'm having some network issues, I'm 
>> not going to start my Ventura VM to look at it right now.
>> 
>> 
>>> On Jun 1, 2023, at 11:17, David Nicholls via macports-users 
>>>  wrote:
>>> 
>>> I upgraded OSX to the latest Ventura, installed the latest Xcode, and Xcode 
>>> tools, accepted the license, then reinstalled Macports as per the 
>>> instructions.  Versions of gcc older than gcc12 failed (as advised in the 
>>> resintall), so I installed gcc12, ran port select to activate gcc12 and 
>>> gfortran12. All ok so far.
>>> 
>>> 'which gcc' gives /opt/local/bin/gcc
>>> 
>>> But:
>>> 
>>> :~ username$ gcc --version
>>> Apple clang version 14.0.3 (clang-1403.0.22.14.1)
>>> Target: x86_64-apple-darwin22.5.0
>>> Thread model: posix
>>> InstalledDir: 
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>>> 
>>> and
>>> 
>>> :~ username$ /opt/local/bin/gcc --version
>>> gcc (MacPorts gcc12 12.3.0_0+stdlib_flag) 12.3.0
>>> Copyright (C) 2022 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>> 
>>> Why does the command 'gcc --version' not give that same result as 
>>> '/opt/local/bin/gcc --version' ?
>>> 
>>> 'gfortan --version' works as expected
>>> 
>>> DN
>>> 
>> 
> 

Re: gcc12 fault?

[Richard L. Hamilton]

Try "type" rather than "which"; "type" is a builtin command in bash, dash, sh, 
and ksh. "which" is typically not a builtin. Usually they should say the same 
thing, but if they're not, something is odd, perhaps with your .bashrc or 
.profile or whatever.

Pretty sure dash is the default shell in Ventura (actually in Monterey too?), 
apparently Apple wasn't thrilled with the bash license.

Nothing else seems obvious, and since I'm having some network issues, I'm not 
going to start my Ventura VM to look at it right now.


> On Jun 1, 2023, at 11:17, David Nicholls via macports-users 
>  wrote:
> 
> I upgraded OSX to the latest Ventura, installed the latest Xcode, and Xcode 
> tools, accepted the license, then reinstalled Macports as per the 
> instructions.  Versions of gcc older than gcc12 failed (as advised in the 
> resintall), so I installed gcc12, ran port select to activate gcc12 and 
> gfortran12. All ok so far.
> 
> 'which gcc' gives /opt/local/bin/gcc
> 
> But:
> 
> :~ username$ gcc --version
> Apple clang version 14.0.3 (clang-1403.0.22.14.1)
> Target: x86_64-apple-darwin22.5.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> 
> and
> 
> :~ username$ /opt/local/bin/gcc --version
> gcc (MacPorts gcc12 12.3.0_0+stdlib_flag) 12.3.0
> Copyright (C) 2022 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> Why does the command 'gcc --version' not give that same result as 
> '/opt/local/bin/gcc --version' ?
> 
> 'gfortan --version' works as expected
> 
> DN
> 

Re: sockstat

[Richard L. Hamilton]

I don't think sockstat would say anything about a port on another system that 
one did not have a connection to, it only reports network activity already 
involving the system it is run on. Telnet could of course attempt to connect. 
And nmap could tell you every port open on the other system (at least to 
packets coming from your system, if some filtering is in use), although some 
might regard an nmap scan as a preliminary to hostilities.

Telnet is in the inetutils port, as gtelnet.

nc can attempt to connect to either TCP or UDP ports, and is included with 
macOS. It has a lot of options, so read the man page carefully.

> On May 12, 2023, at 13:56, André-John Mas  wrote:
> 
> I was looking for it based on a stack overflow article, indicating how to 
> check a server I’d is responding on a given port. 
> 
> Previously I was using telnet for this. 
> 
> André-John
> 
> Sent from my phone. Envoyé depuis mon téléphone.
> 
>> On 12 May 2023, at 13:33, Richard L. Hamilton  wrote:
>> 
>> If it is, I'm not finding it. I'm also not finding it in homebrew.
>> 
>> Looking around, the FreeBSD original is in C, but there is a perl script 
>> version of the same name and somewhat similar description (I did not compare 
>> in detail, and I doubt some of the FreeBSD features are feasible on macOS).
>> 
>> https://github.com/freebsd/freebsd-src/tree/main/usr.bin/sockstat 
>> <https://github.com/freebsd/freebsd-src/tree/main/usr.bin/sockstat>
>> 
>> https://github.com/pj4dev/Mac-Sockstat 
>> <https://github.com/pj4dev/Mac-Sockstat>
>> 
>> 
>> The programs lsof and netstat that come with macOS may provide most of the 
>> same information, even if the usage, selection ability, and output format 
>> are different.
>> 
>> 
>>> On May 12, 2023, at 12:42, André-John Mas >> <mailto:andrejohn@gmail.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Is sockstat available in MacPorts, via a port'. I couldn't find it when 
>>> search for it directly or as 'sostat' (homebrew formula name).
>>> 
>>> Thanks
>>> 
>>> Andre
>>> 
>> 

Re: sockstat

[Richard L. Hamilton]

If it is, I'm not finding it. I'm also not finding it in homebrew.

Looking around, the FreeBSD original is in C, but there is a perl script 
version of the same name and somewhat similar description (I did not compare in 
detail, and I doubt some of the FreeBSD features are feasible on macOS).

https://github.com/freebsd/freebsd-src/tree/main/usr.bin/sockstat 


https://github.com/pj4dev/Mac-Sockstat 


The programs lsof and netstat that come with macOS may provide most of the same 
information, even if the usage, selection ability, and output format are 
different.


> On May 12, 2023, at 12:42, André-John Mas  wrote:
> 
> Hi,
> 
> Is sockstat available in MacPorts, via a port'. I couldn't find it when 
> search for it directly or as 'sostat' (homebrew formula name).
> 
> Thanks
> 
> Andre
> 

Re: Wine

[Richard L. Hamilton]

> On May 1, 2023, at 17:30, James  wrote:
> 
> 
> 
>> On 2 May 2023, at 2:18 am, Richard L. Hamilton  wrote:
>> 
>> Sure, a disposable, isolated environment (esp. one meant for extreme uses, 
>> like a Kali Linux VM) is great for suspicious software...or for testing less 
>> than robust software with possibly maliciously crafted input. Certainly NOT 
>> the example I had in mind, although one might argue that XMP or EXIF (as 
>> applicable) library exploits might make my example risky depending on the 
>> files being processed.
>> 
>> But by that criteria, anything but (maybe) a binary file editor with no size 
>> or content restrictions beyond what the operating system allows could be 
>> vulnerable to maliciously crafted input files, which doesn't even count that 
>> it just might be possible to construct a file name that is an attack on the 
>> OS itself, given complications like UTF-16 normalization, etc.
>> 
>> So IMO the question isn't whether you're running a program (that works fine 
>> in its own environment) in yours with a VM vs some less isolating means, but 
>> whether you'd want to run the program (or run it on certain input) at all 
>> even if it was native, in a valuable environment. I don't know if for 
>> example Wine could be modified to incorporate (invisibly to what it ran) 
>> additional macOS security features like sandboxing, which would make 
>> something run under it not much more dangerous than a native app.
>> 
>> TL/DR: I wouldn't run something that I downloaded and didn't have some 
>> confidence in (recommendations from reputable sites, original download site, 
>> maybe even signed) regardless of whether it was native, in Wine, or in a VM, 
>> unless I was in the business of (properly and carefully) testing software 
>> that didn't even meet that minimum standard of trusted-ness.
>> 
>>> On May 1, 2023, at 09:47, Sean McLinden  wrote:
>>> 
>>> 
>>> Yeah, as long as you aren't analyzing malware. WannaCry in Wine could 
>>> encrypt the contents of the user's HOME directory.
>>> 
>>> - Original Message -
>>> From: "Richard L. Hamilton" 
>>> To: "Sean McLinden" 
>>> Cc: "Christoph Kukulies" , "macports-users list" 
>>> 
>>> Sent: Monday, May 1, 2023 7:44:22 AM
>>> Subject: Re: Wine
>>> 
>>> Sure, but for some things Wine is good enough and even better. Back in 
>>> Mojave (32-bit support) and earlier, one could use WineBottler to make a 
>>> Mac app using Wine that invoked a Windows program. I had that for 
>>> abc_tags.exe, which is more convenient than VLC for fixing batches of 
>>> mis-tagged AVI files. No need to fire up a full VM for that. And yes, I 
>>> have Parallels and VirtualBox and other virtualization products for other 
>>> platforms; nothing against full virtualization, but sometimes it's overkill.
>>> 
>>>> On May 1, 2023, at 07:11, Sean McLinden  wrote:
>>>> 
>>>> 
>>>> If you don't mind spending a few bucks, Parallels Desktop for Mac supports 
>>>> a full-featured Windows 11 VM.
> 
> I've been vaugely following this thread, for the reasons you advocate why not 
> crossover office. Certainly they have been good to me over the years
> James


Costs more than Parallels, so I don't see the point. A free wine to run 
selected Windows apps known to work with it, sure. But a paid one at a fairly 
high price? Not me.

Re: Wine

[Richard L. Hamilton]

Sure, a disposable, isolated environment (esp. one meant for extreme uses, like 
a Kali Linux VM) is great for suspicious software...or for testing less than 
robust software with possibly maliciously crafted input. Certainly NOT the 
example I had in mind, although one might argue that XMP or EXIF (as 
applicable) library exploits might make my example risky depending on the files 
being processed.

But by that criteria, anything but (maybe) a binary file editor with no size or 
content restrictions beyond what the operating system allows could be 
vulnerable to maliciously crafted input files, which doesn't even count that it 
just might be possible to construct a file name that is an attack on the OS 
itself, given complications like UTF-16 normalization, etc.

So IMO the question isn't whether you're running a program (that works fine in 
its own environment) in yours with a VM vs some less isolating means, but 
whether you'd want to run the program (or run it on certain input) at all even 
if it was native, in a valuable environment. I don't know if for example Wine 
could be modified to incorporate (invisibly to what it ran) additional macOS 
security features like sandboxing, which would make something run under it not 
much more dangerous than a native app.

TL/DR: I wouldn't run something that I downloaded and didn't have some 
confidence in (recommendations from reputable sites, original download site, 
maybe even signed) regardless of whether it was native, in Wine, or in a VM, 
unless I was in the business of (properly and carefully) testing software that 
didn't even meet that minimum standard of trusted-ness.

> On May 1, 2023, at 09:47, Sean McLinden  wrote:
> 
> 
> Yeah, as long as you aren't analyzing malware. WannaCry in Wine could encrypt 
> the contents of the user's HOME directory.
> 
> - Original Message -----
> From: "Richard L. Hamilton" 
> To: "Sean McLinden" 
> Cc: "Christoph Kukulies" , "macports-users list" 
> 
> Sent: Monday, May 1, 2023 7:44:22 AM
> Subject: Re: Wine
> 
> Sure, but for some things Wine is good enough and even better. Back in Mojave 
> (32-bit support) and earlier, one could use WineBottler to make a Mac app 
> using Wine that invoked a Windows program. I had that for abc_tags.exe, which 
> is more convenient than VLC for fixing batches of mis-tagged AVI files. No 
> need to fire up a full VM for that. And yes, I have Parallels and VirtualBox 
> and other virtualization products for other platforms; nothing against full 
> virtualization, but sometimes it's overkill.
> 
>> On May 1, 2023, at 07:11, Sean McLinden  wrote:
>> 
>> 
>> If you don't mind spending a few bucks, Parallels Desktop for Mac supports a 
>> full-featured Windows 11 VM.
>> 
>> Sean
>> 
>> 
>> - Original Message -
>> From: "Christoph Kukulies" 
>> To: macports-users@lists.macports.org
>> Sent: Sunday, April 30, 2023 4:45:03 AM
>> Subject: Wine
>> 
>> Does macports support Wine ?
>> 
>> —
>> Christoph
>> 
> 

Re: Wine

[Richard L. Hamilton]

Sure, but for some things Wine is good enough and even better. Back in Mojave 
(32-bit support) and earlier, one could use WineBottler to make a Mac app using 
Wine that invoked a Windows program. I had that for abc_tags.exe, which is more 
convenient than VLC for fixing batches of mis-tagged AVI files. No need to fire 
up a full VM for that. And yes, I have Parallels and VirtualBox and other 
virtualization products for other platforms; nothing against full 
virtualization, but sometimes it's overkill.

> On May 1, 2023, at 07:11, Sean McLinden  wrote:
> 
> 
> If you don't mind spending a few bucks, Parallels Desktop for Mac supports a 
> full-featured Windows 11 VM.
> 
> Sean
> 
> 
> - Original Message -
> From: "Christoph Kukulies" 
> To: macports-users@lists.macports.org
> Sent: Sunday, April 30, 2023 4:45:03 AM
> Subject: Wine
> 
> Does macports support Wine ?
> 
> —
> Christoph
> 

gtk3 on Snow Leopard build failed

[Richard L. Hamilton]

...and things had gone so nicely on Snow Leopard for awhile now, until this:

:notice:build --->  Building gtk3
:debug:build Executing org.macports.build (gtk3)
:info:build --->  Building gtk3 for architecture x86_64
:debug:build setting option build.dir to 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64
:debug:build Environment: 
:debug:build CC_PRINT_OPTIONS='YES'
:debug:build 
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/.CC_PRINT_OPTIONS'
:debug:build CPATH='/opt/local/include'
:debug:build CPLUS_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build C_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build DEVELOPER_DIR='/Developer'
:debug:build LIBRARY_PATH='/opt/local/lib'
:debug:build MACOSX_DEPLOYMENT_TARGET='10.6' 
:debug:build 
MACPORTS_LEGACY_SUPPORT_CPPFLAGS='-isystem/opt/local/include/LegacySupport'
:debug:build MACPORTS_LEGACY_SUPPORT_ENABLED='1' 
:debug:build MACPORTS_LEGACY_SUPPORT_LDFLAGS='-L/opt/local/lib 
-lMacportsLegacySupport'
:debug:build OBJCPLUS_INCLUDE_PATH='/opt/local/include/LegacySupport'
:debug:build OBJC_INCLUDE_PATH='/opt/local/include/LegacySupport'
:info:build Executing:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:debug:build system:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:info:build ninja: error: unknown target 'CC=/opt/local/bin/clang-mp-8.0 -arch 
x86_64'
:info:build Command failed:  cd 
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/work/build-x86_64"
 && /opt/local/bin/ninja -j4 CC='/opt/local/bin/clang-mp-8.0 -arch x86_64' 
CC_FOR_BUILD='/opt/local/bin/clang-mp-8.0 -arch x86_64' -v
:info:build Exit code: 1
:error:build Failed to build gtk3: command execution failed
:debug:build Error code: NONE
:debug:build Backtrace: command execution failed
:debug:build while executing 
:debug:build "$procedure $targetname"
:error:build See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_gnome_gtk3/gtk3/main.log
 for details.



Lest anyone wonder, /opt/local/bin/clang-mp-8.0 does exist.

Re: Cannot build glib2

[Richard L. Hamilton]

> Early MacBook Pro (13", mid 2010), High Sierra 10.13.6 (as far as it will 
> go).
> 
> When doing my weekly port upgrade, it bombs out with:
> 
>--->  Building glib2 
>Error: Failed to build glib2: command execution failed   
>Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_glib2/glib2/main.log
>  for details.
> 
> I see a lot of warnings in main.log such as:
> 
>:info:build ld: warning: The i386 architecture is deprecated for macOS 
> (remove from the Xcode build setting: ARCHS)
> 
> Is this some insidious attempt by Cupertino to force me to buy an M series?

Not insidious, Apple doesn't even know about it, and warnings are not errors 
(although they may be treated as errors if the creator of the build procedure - 
not necessarily the port maintainer - chooses to).

A library, almost certainly libdbus-1 (provided by the dbus port) does not 
support i386 (32-bit) but only x86_64 (64-bit). I verified that with

sh-3.2$ nm /opt/local/lib/libdbus-1.dylib|grep _dbus_message_set_path
0001483c T _dbus_message_set_path

(hex may vary, but " T " should be there indicating the symbol is a defined 
text (function name, usually)  symbol)

That may mean you tried to install glib2 with +universal but did not previously 
install dbus with +universal. Or something like that which has similar results.

Pretty sure that dbus CAN be installed universal, because I have it that way on 
my Snow Leopard VM. Apparently I gave up on installing ports with +universal as 
too much bother on Mojave even though it's the last OS that supports i386, and 
of course I don't have i386 or universal builds on later OSs that don't support 
that. (I don't have anything running High Sierra, so that's as close as I can 
get to your situation)

Building dbus +universal will likely require that every port it depends on (at 
least at runtime) is also built +universal, and it depends on quite a few 
ports. No guarantee that one of them won't be a show-stopper for some reason or 
other (although since I had it built on that Snow Leopard VM, it should likely 
be possible, if very slow).

You really have to look more closely at the log, look for the first line (other 
than the fetching of the downloads, which can fail on some locations before 
succeeding on one of them, i.e. http 404 errors don't count) that has the word 
"error" (case insensitive and followed by a colon to exclude mentions of error 
handing routines and limit it to error messages). And then look back a bit from 
there to see what failed.

In your case (with the "error:" in question and the prior reference to -ldbus-1 
highlighted in red):

:info:build [827/1188] /usr/bin/clang  -o gio/tests/gdbus-serialization 
gio/tests/gdbus-serialization.p/gdbus-serialization.c.o 
gio/tests/gdbus-serialization.p/gdbus-tests.c.o -L/opt/local/lib 
-I/opt/local/include -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names 
-Wl,-undefined,error -Wl,-headerpad_max_install_names -lresolv -bind_at_load 
-arch i386 -pipe -Os -Wno-deprecated-declarations -arch i386 
-Wl,-rpath,@loader_path/../../glib -Wl,-rpath,@loader_path/../../gmodule 
-Wl,-rpath,@loader_path/../../gobject -Wl,-rpath,@loader_path/.. 
-Wl,-rpath,/opt/local/lib glib/libglib-2.0.0.dylib 
gmodule/libgmodule-2.0.0.dylib gobject/libgobject-2.0.0.dylib 
gio/libgio-2.0.0.dylib -lintl -L/opt/local/lib -ldbus-1
:info:build FAILED: gio/tests/gdbus-serialization 
:info:build /usr/bin/clang  -o gio/tests/gdbus-serialization 
gio/tests/gdbus-serialization.p/gdbus-serialization.c.o 
gio/tests/gdbus-serialization.p/gdbus-tests.c.o -L/opt/local/lib 
-I/opt/local/include -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names 
-Wl,-undefined,error -Wl,-headerpad_max_install_names -lresolv -bind_at_load 
-arch i386 -pipe -Os -Wno-deprecated-declarations -arch i386 
-Wl,-rpath,@loader_path/../../glib -Wl,-rpath,@loader_path/../../gmodule 
-Wl,-rpath,@loader_path/../../gobject -Wl,-rpath,@loader_path/.. 
-Wl,-rpath,/opt/local/lib glib/libglib-2.0.0.dylib 
gmodule/libgmodule-2.0.0.dylib gobject/libgobject-2.0.0.dylib 
gio/libgio-2.0.0.dylib -lintl -L/opt/local/lib -ldbus-1
:info:build ld: warning: The i386 architecture is deprecated for macOS (remove 
from the Xcode build setting: ARCHS)
:info:build ld: warning: ignoring file /opt/local/lib/libdbus-1.dylib, file was 
built for x86_64 which is not the architecture being linked (i386): 
/opt/local/lib/libdbus-1.dylib
:info:build Undefined symbols for architecture i386:
:info:build   "_dbus_error_free", referenced from:
:info:build   _get_and_check_serialization in gdbus-serialization.c.o
[many more undefined symbols omitted here]
:info:build ld: symbol(s) not found for architecture i386
:info:build clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
:info:build [828/1188] /usr/bin/clang -Igio/tests/gdbus-server-auth.p 
-Igio/tests 

Re: off-topic question: Apple open command and/or apps in /Applications are half-broken now

[Richard L. Hamilton]

> On Apr 15, 2023, at 15:57, Kenneth Wolcott  wrote:
> 
> Hi;
> 
> off-topic question: Apple open command and/or apps in /Applications
> are half-broken now
> 
> I'm asking the question here because I think that there are lots of
> people who might know either the answer to my question and/or can help
> me find the answer by describing my problem more accurately/precisely.
> 
>  I don't think anything MacPorts did to my Mac via a port
> installation caused this problem.
> 
>  The problem:
> 
> example problem:
> 
> /usr/bin/open -F -a /Applications/Reader.app/Contents/MacOS/Reader 
> some_file.pdf

The usual way is NOT to give the binary to "open", but the app name (without 
path or .app suffix if there's only one match among the places apps are 
searched for, but you might need the suffix if you give a full path, and if 
there's spaces or other problematic characters in the name, you need to quote 
the app name or full path of the app bundle), like this:

/usr/bin/open -F -a Reader
or
/usr/bin/open -F -a /Applications/Reader.app

Whatever library call "open" uses knows about the structure of app bundles and 
how to find the binary and how to invoke it correctly.

Have you tried rebuilding the launch services database? Sometimes it gets 
screwed up, which causes problems launching applications correctly. Google for 
that phrase, or here's one reasonably good description:
https://eclecticlight.co/2017/08/11/launch-services-database-problems-correcting-and-rebuilding/
 


Note that the details may depend on your OS version; I don't have handy nor can 
quickly find a list of OS versions and the exact command(s) for each one, but 
you should be able to figure it out. I do have two versions in scripts, the 
older one

sudo 
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
 -kill -r -domain local -domain system -domain user

and the newer one

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
 -kill -r -domain local -domain system -domain user

The longer path is the real one, but at least on non-ancient macOS versions 
there's a symlink, so either will work. I don't recall whether the sudo was 
necessary more recently, either (maybe never, I don't know).

I don't think lsregister does the work itself, but it communicates what to do 
to another process (one or more of the instances of lsd? of which there's one 
as root, one for the logged in user, and maybe others left over for other user 
ids that have used launch services). That implies that the reset of the per 
user data only applies to the current user.

There's no man page, but running the lsregister command without arguments gives 
a usage message. On Monterey,

sh-3.2$ 
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister
lsregister: [OPTIONS] [ ... ]
  [ -apps [,domain]... ]
  [ -libs [,domain]... ]
  [ -all  [,domain]... ]

Paths are searched for applications to register with the Launch Service 
database.
Valid domains are "system", "local", "network" and "user". Domains can also
be specified using only the first letter.

  -delete   Delete the Launch Services database file. You must then reboot!
  -kill Reset the Launch Services database before doing anything else
  -seed If database isn't seeded, scan default locations for 
applications and libraries to register
  -lint Print information about plist errors while registering bundles
  -lazy n   Sleep for n seconds before registering/scanning
  -rRecursive directory scan, do not recurse into packages or 
invisible directories
  -RRecursive directory scan, descending into packages and 
invisible directories
  -fforce-update registration even if mod date is unchanged
  -uunregister instead of register
  -vDisplay progress information
  -gc   Garbage collect old data and compact the database
  -dump [table] Display full database contents after registration
  -hDisplay this help

With -dump you can get a dump of the database in textual form; it's huge and 
may be tricky to parse, but if you're geeky enough it might be interesting. You 
can dig out the version of a particular app, for instance.

Re: what port(s) give me good control over processes (list, kill, etc) better than MacOS pgrep+pkill

[Richard L. Hamilton]

If you're trying to be exact and ONLY get the process you're probably 
interested in, here's a scenario:

sh-3.2$ pgrep -lf CARROT # list process-id and full command line
911 /Applications/CARROTweather.app/Contents/MacOS/CARROTweather

sh-3.2$ pgrep -l CARROT # list process-id and just command name
911 CARROTweather

sh-3.2$ pgrep -u ${LOGNAME} -x CARROTweather # match only current user-id and 
exact command name
911

With -f, it will match (and with -l, display) the entire command line. Without 
it, it will match (and with -l, display) the command "name", which is the first 
sixteen characters of the last level of the pathname passed to execve(), or 
maybe of argv[0], but I don't think so.

With -x it has to be an exact match, otherwise it just has to match a substring 
(somewhere in what's being matched).

With -u it has to match that user-id too (which can be either numeric or an 
account name).

So the last of those requires specifically the process CARROTweather running 
with my own user-id, and will ignore an instance with any other user-id, such 
as if someone else is logged in graphically with screen sharing/VNC (maybe with 
NX and some other things too if they allow multiple graphical logins)  and also 
running it.

A single user can still have multiple processes of the same name running (such 
as either a command line program or an app opened with the -n option of the 
open command); there would probably be no good and simple way to be sure which 
one was desired.


> On Apr 8, 2023, at 17:20, Kenneth Wolcott  wrote:
> 
> Hi Richard;
> 
>  Thank you for your additional input.
> 
>  Apparently I was over-thinking pgrep+pkill in my earlier attempts.
> 
>  I have implemented your suggestions in my script and it appears to work fine.
> 
> Thanks,
> Ken Wolcott
> 
> On Fri, Apr 7, 2023 at 9:27 PM Richard L. Hamilton  wrote:
>> 
>> Not seeing that, if this fits your scenario:
>> 
>> sh-3.2$ open -a TextEdit
>> sh-3.2$ pgrep -lf TextEdit
>> 68476 /System/Applications/TextEdit.app/Contents/MacOS/TextEdit
>> sh-3.2$ pkill TextEdit
>> # it went away...
>> 
>> SIGTERM is (usually) like Quit; SIGKILL is like Force Quit.
>> 
>> A process may ignore SIGTERM; the signalling process will not be informed of 
>> that. SIGKILL cannot be ignored; although in some Unix implementations, a 
>> hang on what's supposed to be fast I/O (like a physical disk, or an NFS 
>> mount that's "hard" but not "intr") can make a process unkillable, at least 
>> until the hang resolves, if it does; if not, nothing but a reboot will kill 
>> such a process. Some implementations block SIGKILL on process 1, because 
>> process 1 is essential and there's no good reason to do that.
>> 
>> Sometimes the executable in an app bundle does not have the same name as the 
>> app; but a pgrep -lf could match based on the full path includng the app 
>> name.
>> 
>> pgrep or pkill not finding something is not an error, although they'll have 
>> a return code of one.
>> sh-3.2$ pgrep -lf nosuch
>> sh-3.2$ echo $?
>> 1
>> sh-3.2$ pkill nosuch
>> sh-3.2$ echo $?
>> 1
>> 
>> You cannot kill something unless you're root or the same real or effective 
>> userid as it is; there MIGHT be other restrictions, Apple liking to be 
>> tricky about security. But if it exists and you're not allowed to kill it, 
>> that would get an error message:
>> 
>> sh-3.2$ pkill syslogd
>> pkill: signalling pid 161: Operation not permitted
>> 
>> Other than those cases, I don't have further guesses what's happening.
>> 
>> 
>> On Apr 7, 2023, at 23:55, Kenneth Wolcott  wrote:
>> 
>> Hi Richard;
>> 
>> Thanks for the info.  I'll look into those.
>> 
>> I found that a process that I started by using the MacOS open
>> command could be listed by prep but I could not kill it with pkill
>> (silently fails, like a no-op).
>> 
>> sh-3.2$
>> 
> 

Re: what port(s) give me good control over processes (list, kill, etc) better than MacOS pgrep+pkill

[Richard L. Hamilton]

Not seeing that, if this fits your scenario:

sh-3.2$ open -a TextEdit
sh-3.2$ pgrep -lf TextEdit
68476 /System/Applications/TextEdit.app/Contents/MacOS/TextEdit
sh-3.2$ pkill TextEdit
# it went away...

SIGTERM is (usually) like Quit; SIGKILL is like Force Quit.

A process may ignore SIGTERM; the signalling process will not be informed of 
that. SIGKILL cannot be ignored; although in some Unix implementations, a hang 
on what's supposed to be fast I/O (like a physical disk, or an NFS mount that's 
"hard" but not "intr") can make a process unkillable, at least until the hang 
resolves, if it does; if not, nothing but a reboot will kill such a process. 
Some implementations block SIGKILL on process 1, because process 1 is essential 
and there's no good reason to do that.

Sometimes the executable in an app bundle does not have the same name as the 
app; but a pgrep -lf could match based on the full path includng the app name.

pgrep or pkill not finding something is not an error, although they'll have a 
return code of one.
sh-3.2$ pgrep -lf nosuch
sh-3.2$ echo $?
1
sh-3.2$ pkill nosuch
sh-3.2$ echo $?
1

You cannot kill something unless you're root or the same real or effective 
userid as it is; there MIGHT be other restrictions, Apple liking to be tricky 
about security. But if it exists and you're not allowed to kill it, that would 
get an error message:

sh-3.2$ pkill syslogd
pkill: signalling pid 161: Operation not permitted

Other than those cases, I don't have further guesses what's happening.


> On Apr 7, 2023, at 23:55, Kenneth Wolcott  wrote:
> 
> Hi Richard;
> 
>  Thanks for the info.  I'll look into those.
> 
>  I found that a process that I started by using the MacOS open
> command could be listed by prep but I could not kill it with pkill
> (silently fails, like a no-op).
> 
sh-3.2$ 

Re: what port(s) give me good control over processes (list, kill, etc) better than MacOS pgrep+pkill

[Richard L. Hamilton]

While AFAIK there is not a /proc port, there are FUSE based procfs 
implementations for macOS. They are limited in the information they can 
provide, they're using system calls rather than actually digging into the 
kernel, so they can only provide what the system calls they use offer. So I 
don't think you can for example see into a process address space with it.  I 
had it set up some time ago; not sure what FUSE versions or macOS versions it 
would work with, and didn't really think it worth the bother to keep it set up.

The procs port claims to be an advanced ps with more information.

pfind (also in proctools along with pgrep and pkill) looks to offer much more 
powerful selection of processes to list; RTFM.

If permissions allow, lldb should be able to attach to a process, control it, 
inspect it, etc. In addition to owner being the same, some signed or sandboxed 
processes may be able to refuse being attached to or traced.

Don't forget top, Activity Monitor, and (for certain information) lsof.

> On Apr 7, 2023, at 22:39, Kenneth Wolcott  wrote:
> 
> Hi;
> 
> what port(s) give me good control over processes (list, kill, etc)
> better than MacOS pgrep+pkill?
> 
> It would be great if MacOS has /proc filesystem like Linux.
> 
> Thanks,
> Ken Wolcott
> 

Re: WACZ (Web Archive Collection Zipped) software

[Richard L. Hamilton]

I gather that not unlike a Java jar file, a .wacz file is a zip file with 
additional requirements as to layout (and that some components be stored 
(uncompressed) rather than subjected to "deflate" compression (those being 
mostly compressed already).

If that's the case, you could probably rename it to have a .zip suffix and then 
unzip it (preferably in a new empty directory, so it wouldn't leave a mess in a 
directory that already had other files and directories in it).

What you do with it then (to "replay" it or whatever), I have no idea without 
actually getting one and looking at it and trying some things. Although I 
gather you can use the site https://replayweb.page  to 
select an already downloaded .wacz file and replay it. That might work better 
with Chrome than Safari, none of this is anything I've tried.

If you simply want a static representation of what a page seen via the Wayback 
Machine looks like, you might do better to "print" it (possibly in reader view) 
to a pdf file, which you could read with Preview, Adobe Reader, etc.

> On Mar 27, 2023, at 17:07, Eric Gallager via macports-users 
>  wrote:
> 
> So, the Internet Archive has recently added an "Email me a WACZ file
> with the results" option to their "Save Page Now" service in the
> Wayback Machine, so I tried that out and got some WACZ files, although
> now I don't know what to do with them. Is anyone aware of any software
> for handling WACZ files that's available in MacPorts? Or, if there
> isn't any yet, could some be added?
> More info on the format can be found here:
> https://replayweb.page/docs/wacz-format
> There are some python tools for interacting with the format, but I
> couldn't get pypi2port to generate a Portfile for me for them, and
> plus there are kind of too many python things in MacPorts anyways:
> https://github.com/webrecorder/py-wacz
> Anything else?
> Thanks,
> Eric Gallager
> 

Re: [gvim: vim variant?]

[Richard L. Hamilton]

raf, the first person to respond, said:
> I use an Athena (or sometimes Motif) gvim that I
> compiled myself for use in full screen X11, and MacVim
> for use in the macOS native desktop.

MacVim is a separate port from vim. MacVim has a native Mac GUI with its own 
limited settings in the usual preference menu item under the menu bar MacVim 
menu.

The vim port works both in text mode in Terminal (or iTerm or xterm or similar) 
AND optionally graphically with one of various X11 based toolkits.

X11 based use of vim is entirely different from a native Mac GUI, and requires 
an X11 server (Xquartz or the MacPorts xorg-server port, unless you're 
displaying somewhere other than on a Mac) (as well as various build or runtime 
prerequisites).

In cases where one works in a mixed environment with other mostly non-Mac 
systems (like Linux or FreeBSD or whatever), that can be useful because X11 can 
display an individual app running on another system "back" to your desktop (a 
bit like that can be done on Windows using RDP with a special setup), from 
which it can be controlled. Versions of vim that use X11 libraries that use X 
resources are interesting because X resources are loaded into the X11 server, 
and do not depend on a shared home directory to access configuration files 
where the preferences are stored; rather, the application (client) program 
regardless of whether it is running locally or remotely, can simply query for 
them.

> On Mar 25, 2023, at 20:12, Peter West via macports-users 
>  wrote:
> 
> Has MacVim been mentioned?
> —
> Peter West
> p...@pbw.id.au <mailto:p...@pbw.id.au>“Rejoice and be glad, for your reward 
> is great in heaven, for so they persecuted the prophets who were before you.”
> 
>> On 26 Mar 2023, at 10:01 am, raf via macports-users 
>> > <mailto:macports-users@lists.macports.org>> wrote:
>> 
>> On Sat, Mar 25, 2023 at 12:36:05AM -0400, "Richard L. Hamilton" 
>> mailto:rlha...@smart.net>> wrote:
>> 
>>> As an aside, perhaps the best example of using X resources to good
>>> effect to allow a user to adjust a program's behavior and appearance
>>> might be the xephem program (there's a port for that!), which uses
>>> Motif, and has GUI settings that effectively change X resources, which
>>> it can then save for subsequent runs.
>>> 
>>> Otherwise one would end up editing an .Xdefaults file by hand, putting
>>> in mysterious incantations mostly by luck, unless one had studied the
>>> source (or built libXt and libXaw (Athena Widgets) or libXm (Motif)
>>> with editres support, so one could explore the resources and change
>>> them on the fly).
>>> 
>>> Properly compiled and with LD_PRELOAD pointing to the resulting .so
>>> or .dylib, the following may add editres suport on the fly to a Motif
>>> program. Last I checked, it worked on Solaris, and I think I've used
>>> it on macOS, but I haven't tried that in a long time; and right now I
>>> don't think I have a copy of gvim built to use Motif. (I almost forgot
>>> I had this, so I'm not particularly prepared to answer questions about
>>> it.)
>> 
>> Ideally, it shouldn't be too mysterious. I remember seeing
>> Xresources details in manual entries, but looking at gvim's
>> manual entry, I don't see any Xresources specifications. :-(
>> It must be unfashionable.
>> 
>> The editres program seems to be a graphical Xresources editor
>> that lets you explore the resources of a running program.
>> But it looks very cumbersome. I'd prefer documentation and
>> manual editing, but you can't always get what you want. :-)
>> 
>> cheers,
>> raf
>> 
> 

Re: [gvim: vim variant?]

[Richard L. Hamilton]

> On Mar 25, 2023, at 20:01, raf via macports-users 
>  wrote:
> 
> Ideally, it shouldn't be too mysterious. I remember seeing
> Xresources details in manual entries, but looking at gvim's
> manual entry, I don't see any Xresources specifications. :-(
> It must be unfashionable.
> 
> The editres program seems to be a graphical Xresources editor
> that lets you explore the resources of a running program.
> But it looks very cumbersome. I'd prefer documentation and
> manual editing, but you can't always get what you want. :-)

I've rarely seen programs using Xt based libraries (like Athena or Motif) 
document much more than font selection and a handful more, unless they had 
explicit code to fetch and use some resource. Nearly all of that is done 
implicitly by the widgets; and the man pages for the functions composing widget 
libraries layered on the Xt intrinsics DO generally document their resources.

But you need to know an app's widget tree structure to make much use of that. 
Editres (with the helper I posted) can fetch that and save it to a file.

I recently installed vim +huge +x11 +xim +motif

and used the shared object of my use_editres.dylib to use editres to dump 
gvim's widget tree. Each line has two items (none of which is an actual 
resource name or value, they're documented on the widget's man page): the 
official widget name (for which there is likely a man page) and the instance 
name the program assigned to it. Either corresponds to one of the levels of a 
fully qualified resource name, other than the last level (the resource itself, 
give or take that some widgets could be built on other widgets). One might want 
to compose a name with the first name for the program (being more generic) and 
the second name for each widget level (being more specific), and of course 
ultimately the resource name as the last level, followed by colon space value, 
where the requirements for the value are either documented or referenced on the 
widget man page.

Here's the gvim (Motif) widget tree:

Vim  vim
XmForm  vimForm
XmRowColumn  menuBar
XmCascadeButton  subMenu
XmCascadeButton  subMenu
XmCascadeButton  subMenu
XmCascadeButton  subMenu
XmCascadeButton  subMenu
XmCascadeButton  subMenu
XmCascadeButton  subMenu
XmFrame  toolBarFrame
XmRowColumn  toolBar
XmEnhancedButton  Open
XmEnhancedButton  Save
XmEnhancedButton  SaveAll
XmEnhancedButton  Print
XmSeparator  -sep1-
XmEnhancedButton  Undo
XmEnhancedButton  Redo
XmSeparator  -sep2-
XmEnhancedButton  Cut
XmEnhancedButton  Copy
XmEnhancedButton  Paste
XmSeparator  -sep3-
XmEnhancedButton  Replace
XmEnhancedButton  FindNext
XmEnhancedButton  FindPrev
XmSeparator  -sep5-
XmEnhancedButton  LoadSesn
XmEnhancedButton  SaveSesn
XmEnhancedButton  RunScript
XmSeparator  -sep6-
XmEnhancedButton  Make
XmEnhancedButton  RunCtags
XmEnhancedButton  TagJump
XmSeparator  -sep7-
XmEnhancedButton  Help
XmEnhancedButton  FindHelp
XmNotebook  Vim tabline
XmSpinBox  PageScroller
XmTextField  NBTextField
XmArrowButtonGadget  MajorTabScrollerNext
XmArrowButtonGadget  MajorTabScrollerPrevious
XmArrowButtonGadget  MinorTabScrollerNext
XmArrowButtonGadget  MinorTabScrollerPrevious
XmMenuShell  popup_tabline popup
XmRowColumn  tabline popup
XmPushButton  Close
XmPushButton  New Tab
XmPushButton  Open tab...
XmForm  textAreaForm
XmDrawingArea  textArea
XmMenuShell  popup_contextMenu
XmRowColumn  contextMenu
XmPushButton  subMenu
 

Re: [gvim: vim variant?]

[Richard L. Hamilton]

As an aside, perhaps the best example of using X resources to good effect to 
allow a user to adjust a program's behavior and appearance might be the xephem 
program (there's a port for that!), which uses Motif, and has GUI settings that 
effectively change X resources, which it can then save for subsequent runs.

Otherwise one would end up editing an .Xdefaults file by hand, putting in 
mysterious incantations mostly by luck, unless one had studied the source (or 
built libXt and libXaw (Athena Widgets) or libXm (Motif) with editres support, 
so one could explore the resources and change them on the fly).

Properly compiled and with LD_PRELOAD pointing to the resulting .so or .dylib, 
the following may add editres suport on the fly to a Motif program. Last I 
checked, it worked on Solaris, and I think I've used it on macOS, but I haven't 
tried that in a long time; and right now I don't think I have a copy of gvim 
built to use Motif. (I almost forgot I had this, so I'm not particularly 
prepared to answer questions about it.)

/* Here's a way on systems with ELFish dynamic linking to get
 * editres support into source-less binaries, as long as they're
 * dynamically linked with libXt, and are not setuid or setgid.
 * Compile this however you must to produce a shared object,
 * and set the LD_PRELOAD environment variable to point to said
 * shared object, then start your binary, and enjoy.
 *
 * using gcc on Solaris, one might do something like:
 * gcc -I$(OPENWINHOME)/include -mno-app-regs -fPIC -G -c use_editres.c
 * ld -G -L$(OPENWINHOME)/lib -R$(OPENWINHOME)/lib -lXt -lXmu -o 
use_editres.so
 *
 * env LD_PRELOAD=./use_editres.so program [args]
 *
 * This works for me with CDE binaries on Solaris, and I'd like to
 * think that with at most a few changes it would also work on Linux.
 *
 * It works by trapping access to the internal (but global) functions
 * that at least R5 through R6.3 libXt uses to implement the four
 * shell widget creation functions (two each traditional and varargs),
 * calling the corresponding real functions, and if they successfully
 * returned a widget, adding the editres event handler to those widgets,
 * and returning the value that the real function returned.
 *
 * This is modelled on various similar examples by others that use
 * LD_PRELOAD to modify the behavior of pre-existing routines, as well
 * as the description in the Motif FAQ of how to alter the source of
 * an application to use editres with Motif.
 *
 * This is only the 2nd X related program I've written, (there's enough
 * command line and batch stuff to keep me from being bored, and I'm a
 * command line kinda guy), so if it has problems that I'm not aware of,
 * let me know - I may not know how to fix them, but would at least want to
 * learn to recognize them.

 *
 * R Hamilton, 19 June 98   rlha...@smart.net
 */
#include 
#include 
#include 

typedef void *XtTypedArgList; /* bogus, but gets around stuff hidden in
  private libXt include file */

Widget _XtCreatePopupShell(name, widget_class, parent, args, num_args,
   typed_args, num_typed_args)
   String name;
   WidgetClass widget_class;
   Widget parent;
   ArgList args;
   Cardinal num_args;
   XtTypedArgList typed_args;
   Cardinal num_typed_args;
{
   static Widget (*_XtCreatePopupShell_Real)();
   Widget retval;

   if (_XtCreatePopupShell_Real==NULL)
  _XtCreatePopupShell_Real = (Widget (*) ())
 dlsym(RTLD_NEXT, "_XtCreatePopupShell");

   if ((retval = _XtCreatePopupShell_Real(name,widget_class,parent,args,
 num_args, typed_args,num_typed_args)) != NULL)
  XtAddEventHandler(retval, (EventMask)0, True,
 _XEditResCheckMessages, NULL);
   return retval;
}

Widget _XtAppCreateShell(name, class, widget_class, display, args, num_args,
 typed_args, num_typed_args)
   String name, class;
   WidgetClass widget_class;
   Display* display;
   ArgList args;
   Cardinal num_args;
   XtTypedArgList typed_args;
   Cardinal num_typed_args;
{
   static Widget (*_XtAppCreateShell_Real)();
   Widget retval;

   if (_XtAppCreateShell_Real==NULL)
  _XtAppCreateShell_Real = (Widget (*) ())
 dlsym(RTLD_NEXT, "_XtAppCreateShell");

   if ((retval = _XtAppCreateShell_Real(name,class,widget_class,display,
 args, num_args, typed_args,num_typed_args)) != NULL)
  XtAddEventHandler(retval, (EventMask)0, True,
 _XEditResCheckMessages, NULL);
   return retval;
}



> On Mar 24, 2023, at 23:51, raf via macports-users 
>  wrote:
> 
> On Fri, Mar 24, 2023 at 05:12:33PM +, Maxim Abalenkov 
>  wrote:
> 
>> Dear all,
>> 
>> How are you? I hope all is well with you. I need your help please. I
>> mostly work in the terminal and use vim as my text editor. But
>> occasionally I need a text editor with a graphical user interface. I
>> have heard good things about ‘gvim’. Would you please tell me, how
>> to install ‘gvim’ with MacPorts? 

Re: Request for support

[Richard L. Hamilton]

I've seen web pages mention the use of wget to back up websites, and mention 
using either MacPorts or Homebrew to install wget (which doesn't come with 
macOS).

They also seem to suggest that rsync over ssh might be better (no credentials 
in the clear, unlike wget using ftp). MacOS does include rsync, but one might 
want a newer version for some reason.

Both being command line and capable of other uses, one still needs to know how 
to use them. :-)

If the website includes a database, one may also need ssh access to run a 
database dumping tool (since a database can be a moving target, you may not 
want to simply copy the underlying files).

Not something I've done, just the result of a couple of minutes of googling. 
Me, if there were no databases, I'd set up ssh access and use tar or cpio or 
rsync to do the copying. Rsync is likely more efficient in terms of bandwidth, 
but I have seen it choke on synchronizing REALLY large directory trees.

> On Mar 12, 2023, at 20:49, Craig Treleaven  wrote:
> 
>> On Mar 12, 2023, at 5:35 PM, Sarah Zinsmeister > > wrote:
>> 
>> I actually thought this was a program to back up websites
> 
> As others have said, you can leave Macports installed without any risk.  Or 
> uninstall it if you don’t intend to use it.
> 
> However, perhaps we can help you achieve the goal of backing up websites.  If 
> you found this idea on the web, could you post a link so that we can help you 
> work through what may be required?
> 
> Craig
> 

Re: rebuilding / upgrading a package at the same version

[Richard L. Hamilton]

I use

port -n upgrade --force --no-rev-upgrade portname

The -n prevents rebuilding everything portname depends on (which would 
otherwise happen with --force ). The --force and --no-rev-upgrade should be 
obvious.

You should do a

port clean portname

first, but if you are going to build with

configure.compiler=something_other_than_previously_used

you have to, or it will likely refuse to build because the leftover build 
information doesn't match.


> On Mar 9, 2023, at 17:35, Riccardo Mottola via macports-users 
>  wrote:
> 
> Hi,
> 
> 
> Riccardo Mottola via macports-users wrote:
>> Hi,
>> 
>> how can I rebuild a port without it being detected as "upgrade" because it 
>> stays at the same version?
>> It may happen because rev-upgrade detects it but fails to build (e.g. want 
>> to change the compiler) or because for some strange reason rev-upgrade fails 
>> to detect and I want to rebuild it anyway.
>> 
>> upgrade maintains variants and also the status if the package was requested 
>> or not, as well as not needing to mess with dependencies.
>> 
>> 
> 
> I ask again...
> Any "way to force a rebuild/reinstall? I need it not only to be able to set 
> the compiler, but also to be able to selectively upgrade. E.g. rev-upgrade 
> detects 5 ports, if the first fails, it continues failing there, I want to 
> manually rebuild the others.
> 
> Thanks,
> 
> Riccardo
> 

tool for software security check?

[Richard L. Hamilton]

Saw https://owasp.org/www-project-dependency-check/ 


and that it can run on Macs given that homebrew seems to support it.

If there was a macports port of it, could that be run on macports ports (maybe 
even on the buildbots) to make sure that known vulnerability issues (fixable 
with updates, perhaps) aren't missed?

Re: Install on Ventura 14.2

[Richard L. Hamilton]

Guessing that the file you saw growing might have been a temporary name for a 
large archive file being downloaded, and for whatever reason (not necessarily 
on your end) the download was very slow.

> On Feb 2, 2023, at 8:54 PM, Jim Secan  wrote:
> 
> Ran for almost an hour, but finally did stop successfully.  At this point I’m 
> just kinda curious as to what it was doing that took that long?
> 
> Jim
> 3222 NE 89th St
> Seattle, WA 98115
> (206) 430-0109
> 
> 

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

[Richard L. Hamilton]

> On Jan 17, 2023, at 11:08 PM, Fielding, Eric J (US 329A) via macports-users 
>  wrote:
> 
> I was running “port selfupdate” and “port upgrade outdated” for the first 
> time in a while, and I noticed that my Intel MacBook Pro was spending almost 
> an hour compiling a port called “ghc” that I don’t remember seeing before and 
> I am sure I did not request. Is this part of something else that was added 
> recently that is now a dependency of some other port?
>  
> Thanks,
> ++Eric

I don’t know whether some recent updated to another port that previously didn’t 
depend on it now does, but here’s what it is, and below, what depends on it.


sh-3.2$ port info ghc
ghc @9.4.4_1 (lang, haskell)
Sub-ports:ghc-prebuilt, hadrian
Variants: prebuilt, universal

Description:  The Glasgow Haskell Compiler is a robust, fully-featured,
  optimising compiler and interactive environment for
  Haskell 98, GHC compiles Haskell to either native code or
  C. It implements numerous experimental language extensions
  to Haskell 98, for example: concurrency, a foreign
  language interface, multi-parameter type classes, scoped
  type variables, existential and universal quantification,
  unboxed types, exceptions, weak pointers, and so on. GHC
  comes with a generational garbage collector, and a space
  and time profiler.
Homepage: https://haskell.org/ghc

Fetch Dependencies:   gnupg2
Extract Dependencies: xz
Patch Dependencies:   cabal-prebuilt, ghc-prebuilt
Build Dependencies:   alex, bash, bzip2, cctools, gzip, hadrian, happy,
  HsColour, python310, py310-sphinx, texlive,
  texlive-fonts-extra, texlive-fonts-recommended,
  texlive-latex-extra, xz, autoconf, automake, libtool,
  cabal-prebuilt, ghc-prebuilt, gsed
Library Dependencies: gmp, libiconv, ncurses
Platforms:darwin
License:  BSD
Maintainers:  Email: s.t.sm...@ieee.org, GitHub: essandess
  Policy: openmaintainer

sh-3.2$ port echo rdepends:ghc
adblock2privoxy 
aeson-pretty
bali-phy
bladeRF 
cabal   
cpphs   
Djinn   
DoCon   
exa 
git-annex   
git-fuzzy   
gocryptfs   
gqrx
gr-osmosdr  
gr-rds  
gr-specest  
gr37-osmosdr
gr37-rds
gr37-specest
gtk2hs  
haskell-mode.el 
HaXml   
hlint   
ihaskell
jo  
lhs2tex 
macos-fortress  
macos-fortress-easylistpac  
macos-fortress-proxy
macos-fortress-proxy-squid  
matterhorn  
mod_tile
ngs 
Omega   
osmium-tool 
pandoc  
pure-gen
shellcheck  
SoapyBladeRF

Re: question on py-simpy

[Richard L. Hamilton]

sh-3.2$ port contents py-simpy
Port py-simpy contains:
  /opt/local/share/doc/py-simpy/README

sh-3.2$ cat /opt/local/share/doc/py-simpy/README
py-simpy is a stub port

(installing it causes py39-simpy to be installed)

sh-3.2$ port contents py39-simpy
Port py39-simpy contains:
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy-4.0.1-py3.9.egg-info/PKG-INFO
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy-4.0.1-py3.9.egg-info/SOURCES.txt
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy-4.0.1-py3.9.egg-info/dependency_links.txt
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy-4.0.1-py3.9.egg-info/not-zip-safe
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy-4.0.1-py3.9.egg-info/top_level.txt
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/__init__.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/__pycache__/__init__.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/__pycache__/core.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/__pycache__/events.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/__pycache__/exceptions.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/__pycache__/rt.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/__pycache__/util.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/core.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/events.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/exceptions.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/py.typed
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/__init__.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/__pycache__/__init__.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/__pycache__/base.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/__pycache__/container.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/__pycache__/resource.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/__pycache__/store.cpython-39.pyc
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/base.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/container.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/resource.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/resources/store.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/rt.py
  
/opt/local/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/simpy/util.py


> On Jan 8, 2023, at 10:30 AM, Giuseppe 'ferdy' Miceli  wrote:
> 
> ciao,
> 
> as rule of thumb, python modules ports have supbort for different python 
> version.
> 
> you can see what specific python version subport the generic port install 
> (based on your default variants in /etc/macports/variants.conf) 
> looking at the library dependencies.
> 
> py-simpy @4.0.1_1 (python)
> Sub-ports:py37-simpy, py38-simpy, py39-simpy, py37-simpy-docs, 
> py38-simpy-docs, py39-simpy-docs
> 
> Description:  SimPy is an object-oriented, process-based 
> discrete-event simulation language based on standard Python.
> Homepage: https://simpy.readthedocs.io
> 
> Library Dependencies: py39-simpy
> 
> 
> thus: no, this is not a conflict and no, you are not supposed to uninstall 
> any of them.
> 
> hth,
> — 
> ferdy
> 
>> On 8 Jan 2023, at 15:32, Artemio González López via macports-users 
>>  wrote:
>> 
>> I just installed py39-simpy, without realizing that py-simpy was actually 
>> installed. So now
>> 
>> port installed py\*-simpy
>> 
>> produces
>>  
>> The following ports are currently installed:
>>   py-simpy @4.0.1_1 (active)
>>   py39-simpy @4.0.1_0 (active)
>> 
>> Is this a conflict? 

Re: symlink points to itself or nowhere

[Richard L. Hamilton]

I don’t think that should happen! Certainly a link like that does nothing 
useful, just causes errors. For example:

sh-3.2$ ln -s bogus bogus
sh-3.2$ ln -s '' bogus2

sh-3.2$ ls -l bogus*
lrwxr-xr-x  1 rlhamil  wheel  5 Jan  6 13:39 bogus -> bogus
lrwxr-xr-x  1 rlhamil  wheel  0 Jan  6 13:40 bogus2 -> 

sh-3.2$ ls -lL bogus*
lrwxr-xr-x  1 rlhamil  wheel  5 Jan  6 13:39 bogus -> bogus
lrwxr-xr-x  1 rlhamil  wheel  0 Jan  6 13:40 bogus2 ->
ls: bogus: Too many levels of symbolic links
ls: bogus2: No such file or directory

Ordinarily you can remove a bad symlink, i.e. per the above example

sh-3.2$ rm bogus bogus2

But I don’t recommend that here (see below).

python3 is optional and a selectable way to provide a default shorter name, and 
resolves to one of the python 3 versions as shown below:

sh-3.2$ port select --list python3
Available versions for python3:
none (active)
python310
python311
python34
python36
python37
python38
python39

sh-3.2$ port select --show python3
The currently selected version for 'python3' is 'none'.

You can choose one of those listed  (including none, to get rid of the links) 
with something like (with then last argument being one of the above ports that 
you have installed):

sh-3.2$ sudo port select --set python3 python39

Rather than removing the bad link directly, I’d do

sh-3.2$ sudo port select --set python3 none

(so that any record keeping is also updated, and any other associated links are 
also cleaned up) I might do that before I did it again with some value other 
than “none” if I wanted that end result, just to be paranoid.

Only if selecting “none” fails (I don’t know how much error checking is done) 
would I delete the link with “rm”.



> On Jan 6, 2023, at 1:30 PM, list_email--- via macports-users 
>  wrote:
> 
> /opt/local/bin/python3 is a symlink that points to itself (Path Finder) or to 
> nowhere (Finder). Is that correct?
> 
> Jerry
> 
> 
> M 480 612 4252
> L 480 839 3708
> 
> 

Re: list of packages that are always compiled

[Richard L. Hamilton]

> On Dec 26, 2022, at 8:43 AM, Joshua Root  wrote:
> 
> https://github.com/macports/macports-infrastructure/blob/master/jobs/port_binary_distributable.tcl
>  
> 
> List which ports are and aren't considered distributable: 
>  >


For those it seems one also needs 
https://github.com/macports/macports-infrastructure/blob/master/jobs/distributable_lib.tcl
 

 in the current directory.

A plausible test case with the first of those (ffmpeg +nonfree) gave the 
expected result: return code 1, i.e. non-redistributable; and without the 
+nonfree variant, also gave the expected result of return code 0 
(redistributable). That nicely shows that the results reflect the effects of 
dependency differences based on variant.

Does the behavior of those take into account configuration like a modified 
variants.conf (so the result aligns with what variants would be used if one did 
a port install)? I’’m not remotely familiar with the behavior of the various 
MacPorts tcl routines called, and barely familiar with tcl.

But generally this does seem to answer the OP’s questions nicely, even if not 
as part of the “port” command itself; although both of the scripts that obtain 
the information for all ports are quite slow; and while I personally hadn’t 
been concerned with discovering that information, it could sometimes be useful 
so I also appreciate the info and scripts!

For speed, perhaps for finding out which ports were prebuilt, a server-side 
script could simply look for all the binary archives and filter it for a given 
macOS (Darwin) version much more quickly; then a single http(s) request could 
retrieve that information; depending on how large the all versions vs single 
version result might be, one could let the filtering happen on the client side 
if that wouldn’t generate too much network traffic. Even faster would be if the 
list of binary archives was cached, although that might not be worth the 
bother. Likewise if redistributable status for default (assuming vanilla 
variants.conf) variants was cached. There are a few things like redistributable 
status and maybe install date (I recall someone asking about whether that could 
be determined) that would be interesting as extra fields in the registry, 
although that clearly implies a new MacPorts version AND some migration issues 
(and some information only being available for ports installed or updated after 
the update and migration).

I suspect that redistributable status may (if one wants to redistribute 
binaries) be more widely useful than knowing the availability of pre-built 
binaries, given that the latter will likely not include everything permissible, 
and may change anytime a port or something it depends on changes.

Re: list of packages that are always compiled

[Richard L. Hamilton]

There are license and license_noconflict lines in Portfiles; if a port and what 
it depends on (including include files, no pun intended) are incompatible (I 
suppose assumed if they are different unless a license_noconflict line in one 
(both?) Portfile says it’s ok), then that port cannot be distributed in binary.

Only default variants will be prebuilt. That’s not just when you specify a 
non-default variant on “port install”, it’s also affected by changes you might 
have made to variants.conf.

A Portfile with
known_fail   yes
in it will not be built automatically, but will per the documentation also 
prompt the user if they really want to attempt to install it.

There may be other reasons I’m not aware of. There is a variant called 
+use_source, which may even be default for some ports, but I haven’t seen a 
good explanation of it. I can imagine that there might be ports best compiled 
on each system that uses them, so as to take advantage of hardware specific 
optimizations peculiar to a particular CPU or GPU (or other?) model, but I 
don’t know that such exist nor what if anything they would do to only be 
available in source.

Builds can fail, and there aren’t enough/active enough port maintainers to 
follow up on fixing everything that breaks - sad in a way, because if they 
could, that would catch failures on e.g. OS versions they did not themselves 
run and test on. In a perfect world, build failures could automatically 
generate tickets. :-)

If there was a magic way to search all Portfiles for those and possibly other 
keywords and analyze the results, it might be possible to determine what 
binaries SHOULD be available for (IF the last build attempt succeeded AND there 
is even a buildbot for that particular OS version).

I’m not sufficiently familiar with everything to be certain that what you want 
does not exist…but did not find it in a quick scan of the “port” man page and 
of guide.macports.org (could have missed it, that’s a lot for a quick scan!).

> On Dec 25, 2022, at 12:49 AM, Werner LEMBERG  wrote:
> 
> 
> Folks,
> 
> 
> is there an option to `port` that shows me the names of all packages
> that must be built from source, and which are not available
> pre-compiled from 'packages.macports.org'?  Or maybe this list is
> somewhere else, ideally also giving a reason?  [My use-case is
> 'ghostscript', for which I can't see why it is not provided
> pre-compiled.]
> 
> Right now, I check 'packages.macports.org' directly whether there is a
> directory, but this is inefficient IMHO – and it doesn't give the
> reason :-)
> 
> 
>Werner
> 

Re: a2ps fails to install (compressed log attached)

[Richard L. Hamilton]

I have a Ventura VM (with Xcode and command line tools installed), and it’s not 
there, although there’s a man page in the Monterey SDK for the command line 
tools.

> On Dec 20, 2022, at 9:30 AM, Marc Wilson  wrote:
> 
> I don’t have a Ventura machine to check, but /usr/bin/makeinfo is certainly 
> present in Monterey.
> 
> $ ll /usr/bin/makeinfo 
> -rwxr-xr-x  1 root  wheel  611936 Dec  2 00:43 /usr/bin/makeinfo*
> 
> -- 
> Marc Wilson
> posgu...@gmail.com 

Re: dead man page links?

[Richard L. Hamilton]

created:
https://trac.macports.org/ticket/65999 fsp 
https://trac.macports.org/ticket/66000 gimp2
https://trac.macports.org/ticket/66001 xxhash


> On Oct 15, 2022, at 5:05 AM, Ryan Schmidt  wrote:
> 
> On Oct 1, 2022, at 01:39, Richard L. Hamilton wrote:
>> 
>> Given a bunch of No such file or directory errors from man -k and/or 
>> /usr/libexec/makewhatis, I looked a bit, and
>> 
>> /opt/local/share/man/man1/dot2gxl.1 is provided by: graphviz
>> /opt/local/share/man/man1/fcat.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fcd.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fdu.1.gz is provided by: fsp
>> /opt/local/share/man/man1/ffind.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fget.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fgrab.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fhost.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fls.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fmv.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fpro.1.gz is provided by: fsp
>> /opt/local/share/man/man1/frm.1.gz is provided by: fsp
>> /opt/local/share/man/man1/frmdir.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fsetup.1.gz is provided by: fsp
>> /opt/local/share/man/man1/fstat.1.gz is provided by: fsp
>> /opt/local/share/man/man1/gimp-console.1 is provided by: gimp2
>> /opt/local/share/man/man1/xxh128sum.1 is provided by: xxhash
>> /opt/local/share/man/man1/xxh32sum.1 is provided by: xxhash
>> /opt/local/share/man/man1/xxh64sum.1 is provided by: xxhash
>> 
>> all turn out to be symlinks to nonexistent files. What’s up with that? I 
>> certainly didn’t remove man pages manually.
> 
> Please file a separate bug report for each individual affected port, for 
> which a bug report does not already exist, so that each issue can be 
> investigated and fixed separately.
> 
> The bug report about graphviz for example is 
> https://trac.macports.org/ticket/61288 so you don't need to file that one. I 
> haven't checked if the others have bug reports already.
> 
> 

Re: Does the migration procedure keep ports versions?

[Richard L. Hamilton]

See 
https://www.macworld.com/article/673939/this-is-how-long-macs-and-macbooks-last.html
 

and in particular down at the section entitled "When do Macs become obsolete?”

This is NOT worse than Windows.
https://www.computerworld.com/article/3209977/windows-10-is-making-too-many-pcs-obsolete.html
 

https://www.protecrecycling.com/windows-11-and-computer-recycling/ 


etc.

One can of course still run Linux, probably still with updates, on many Windows 
boxes and some Macs, possibly without support of every peripheral or hardware 
feature; but older Macs would actually be likely to do better there.

OTOH, if kept clean, hardware can last longer, esp. with an SSD rather than a 
spinning disk. And some other hardware can last MUCH longer; I have a low-end 
Sun workstation (Sun Blade 100) that’s about 21 years old, and aside from some 
disk replacements (there are two, mirrored, so a single failure replaced 
reasonably promptly doesn’t lose anything), it just keeps running, if slowly by 
modern standards. Eventually I’ll migrate my slow home email server from there 
to a six years younger and far more powerful machine (but probably with most 
speedup being more RAM and much newer IMAP server software). But the Suns were 
built with overkill for airflow and everything else pertaining to reliability 
(rather than elegance or even performance), which is NOT particularly quiet or 
compact.


> On Sep 30, 2022, at 8:22 PM, Dave Horsfall  wrote:
> 
> On Thu, 29 Sep 2022, chilli.names...@gmail.com wrote:
> 
> [...]
> 
>> When HS was first released, I swear it wasn't supported on 2010, and 
>> there was the typical expected uproar from customers, and a High Sierra 
>> patcher tool was quickly released by an independent developer 
>> (possibly http://dosdude1.com/software.html ) allowing models back to 
>> 2008 to install it, But according to MacTracker, High Sierra is 
>> supported on 2010 MBP.  Maybe I had it wrong, maybe Apple had a change 
>> of heart.
> 
> Interesting; I didn't have to use that tool, as it "just worked" and my 
> local Mac shop (from whom I bought my 2nd-hand MBP) recommended Sierra 
> only.
> 
> But I wanted to use Garage Band etc.
> 
> Apple is trying to force me (a pensioner) to buy the very latest, but I 
> don't see them contributing towards the cost...
> 
> -- Dave

dead man page links?

[Richard L. Hamilton]

Given a bunch of No such file or directory errors from man -k and/or 
/usr/libexec/makewhatis, I looked a bit, and

/opt/local/share/man/man1/dot2gxl.1 is provided by: graphviz
/opt/local/share/man/man1/fcat.1.gz is provided by: fsp
/opt/local/share/man/man1/fcd.1.gz is provided by: fsp
/opt/local/share/man/man1/fdu.1.gz is provided by: fsp
/opt/local/share/man/man1/ffind.1.gz is provided by: fsp
/opt/local/share/man/man1/fget.1.gz is provided by: fsp
/opt/local/share/man/man1/fgrab.1.gz is provided by: fsp
/opt/local/share/man/man1/fhost.1.gz is provided by: fsp
/opt/local/share/man/man1/fls.1.gz is provided by: fsp
/opt/local/share/man/man1/fmv.1.gz is provided by: fsp
/opt/local/share/man/man1/fpro.1.gz is provided by: fsp
/opt/local/share/man/man1/frm.1.gz is provided by: fsp
/opt/local/share/man/man1/frmdir.1.gz is provided by: fsp
/opt/local/share/man/man1/fsetup.1.gz is provided by: fsp
/opt/local/share/man/man1/fstat.1.gz is provided by: fsp
/opt/local/share/man/man1/gimp-console.1 is provided by: gimp2
/opt/local/share/man/man1/xxh128sum.1 is provided by: xxhash
/opt/local/share/man/man1/xxh32sum.1 is provided by: xxhash
/opt/local/share/man/man1/xxh64sum.1 is provided by: xxhash

all turn out to be symlinks to nonexistent files. What’s up with that? I 
certainly didn’t remove man pages manually.

Her’s the bad links:

lrwxr-xr-x  1 root  wheel8 Sep 22 03:21 /opt/local/share/man/man1/dot2gxl.1 
-> gv2gxl.1
lrwxr-xr-x  1 root  admin  140 Sep 20 12:43 /opt/local/share/man/man1/fcat.1.gz 
-> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fcatcmd.1.gz
lrwxr-xr-x  1 root  admin  139 Sep 20 12:43 /opt/local/share/man/man1/fcd.1.gz 
-> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fcdcmd.1.gz
lrwxr-xr-x  1 root  admin  139 Sep 20 12:43 /opt/local/share/man/man1/fdu.1.gz 
-> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fducmd.1.gz
lrwxr-xr-x  1 root  admin  141 Sep 20 12:43 
/opt/local/share/man/man1/ffind.1.gz -> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/ffindcmd.1.gz
lrwxr-xr-x  1 root  admin  140 Sep 20 12:43 /opt/local/share/man/man1/fget.1.gz 
-> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fgetcmd.1.gz
lrwxr-xr-x  1 root  admin  141 Sep 20 12:43 
/opt/local/share/man/man1/fgrab.1.gz -> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fgrabcmd.1.gz
lrwxr-xr-x  1 root  admin  141 Sep 20 12:43 
/opt/local/share/man/man1/fhost.1.gz -> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fhostcmd.1.gz
lrwxr-xr-x  1 root  admin  139 Sep 20 12:43 /opt/local/share/man/man1/fls.1.gz 
-> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/flscmd.1.gz
lrwxr-xr-x  1 root  admin  139 Sep 20 12:43 /opt/local/share/man/man1/fmv.1.gz 
-> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fmvcmd.1.gz
lrwxr-xr-x  1 root  admin  140 Sep 20 12:43 /opt/local/share/man/man1/fpro.1.gz 
-> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fprocmd.1.gz
lrwxr-xr-x  1 root  admin  139 Sep 20 12:43 /opt/local/share/man/man1/frm.1.gz 
-> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/frmcmd.1.gz
lrwxr-xr-x  1 root  admin  142 Sep 20 12:43 
/opt/local/share/man/man1/frmdir.1.gz -> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/frmdircmd.1.gz
lrwxr-xr-x  1 root  admin  142 Sep 20 12:43 
/opt/local/share/man/man1/fsetup.1.gz -> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fsetupcmd.1.gz
lrwxr-xr-x  1 root  admin  141 Sep 20 12:43 
/opt/local/share/man/man1/fstat.1.gz -> 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_net_fsp/fsp/work/destroot/opt/local/share/man/man1/fstatcmd.1.gz
lrwxr-xr-x  1 root  wheel   19 Aug 18 02:13 
/opt/local/share/man/man1/gimp-console.1 -> gimp-console-2.10.1
lrwxr-xr-x  1 root  admin   12 Dec 29  2021 
/opt/local/share/man/man1/xxh128sum.1 -> cli/xxhsum.1
lrwxr-xr-x  1 root  admin   12 Dec 29  2021 
/opt/local/share/man/man1/xxh32sum.1 -> cli/xxhsum.1
lrwxr-xr-x  1 root  admin   12 Dec 29  2021 

Re: Does the migration procedure keep ports versions?

[Richard L. Hamilton]

Doubtless someone will correct me if wrong, but I don’t think so. AFAIK, the 
“port” command cannot install an arbitrary version unaided, only the latest 
version. But one can go to the repository and fetch an older version of a 
particular port’s Portfile and use the “port” command with that, and depending 
on whether it will build with newer versions of what it depends on (or if one 
manually repeats as needed for them), usually get the older version built and 
installed. I’ve had to do that a time or two (unrelated to migration), when a 
newer version was a problem for me, but it’s been long enough ago that I didn’t 
keep notes, although it has been explained on-list at least once.

An older version might not be possible sometimes esp. across such a big OS 
version jump, as eventually system headers and interfaces change incompatibly 
or more likely some are deprecated/eliminated (i.e. anything only 32-bit after 
Mojave).

AFAIK, the migration procedure does preserve variants and CAN preserve 
requested/unrequested status.

> On Sep 29, 2022, at 3:58 AM, Ces VLC  wrote:
> 
> Hi!
> 
> I'm planning an update of a High Sierra MBP up to Monterey, and I didn't find 
> an explicit mention in the migration docs 
> (https://trac.macports.org/wiki/Migration 
> ) about if the described procedure 
> keeps the ports versions or not. In this moment that's important for me, 
> because I have some compilers (like mingw-w64, for example), and I want to 
> keep them at the same version they are now, because of some compatibility 
> needs.
> 
> Kind regards and thanks a lot,
> 
> César
> 

Re: Unable to build XV

[Richard L. Hamilton]

Something else that worked since back in the day, and is not broken: 
ImageMagick and its “display” command. Interface is different and not all 
functionality has parallels (although mostly “display” does more), but an 
alternative in the hopefully temporary absence of xv. It does not have its own 
widgets, so openmotif is also required.

> On Sep 18, 2022, at 8:11 PM, Dave Horsfall  wrote:
> 
> On Sun, 18 Sep 2022, Richard L. Hamilton wrote:
> 
>> I’ve not only seen that across various macOS versions, but something 
>> else broke the existing xv because one of the ports the older version 
>> depended on changed where it keeps some libraries. Specifically, the 
>> older version of xv expects
> 
> [..]
> 
> Grumble...  So I see :-(
> 
> I like XV (been using it since SunOS) so I'll try your fix.
> 
> -- Dave

Re: Unable to build XV

[Richard L. Hamilton]

I’ve not only seen that across various macOS versions, but something else broke 
the existing xv because one of the ports the older version depended on changed 
where it keeps some libraries. Specifically, the older version of xv expects

/opt/local/lib/libjasper.4.dylib

but the new location for that seems to be

/opt/local/libexec/jasper2/lib/libjasper.4.dylib

So there are definitely issues between xv and jasper2.

I worked around the existing broken xv binary using a symlink for the library 
(which if it all gets fixed, I’ll remove by hand as I created it by hand). But 
other than that, I have no particular familiarity with the innards of either xv 
or jasper2, although many years ago I compiled xv for Solaris.

> On Sep 18, 2022, at 7:37 PM, Dave Horsfall  wrote:
> 
> Mid-2010 MacBook Pro w/ High Sierra 10.13.6 (as far as it will go)
> 
> I'll understand if XV is no longer supported (it's quite long in the 
> tooth), but I find it better than GIMP for my requirements.
> 
> Anyway...
> 
>--->  Building xv
>Error: Failed to build xv: command execution failed  
>Error: See 
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_graphics_xv/xv/main.log
>  for details.
>Error: Follow https://guide.macports.org/#project.tickets if you believe 
> there is a bug.
> 
> Extract from main.log (compressed log attached):
> 
>:info:build /usr/bin/clang -Os -arch x86_64 -DDOPNG -I/opt/local/include 
> -I/opt/local/include -DDOJPEG -I/opt/local/include -DDOTIFF 
> -DUSE_TILED_TIFF_BOTLEFT_FIX -I/opt/local/include -DDOPDS -DDOJP2K 
> -I/opt/local/libexec/jasper2/include  -DMGCSFXDIR=\"/opt/local/lib/xv\"  
> -D__DARWIN__   -DUSLEEP -DDOCDIR=\"/opt/local/share/doc/xv\" 
> -DSYSCONFDIR=\"/etc\" -DXVEXECPATH=\"/opt/local/lib/xv\" -o bggen bggen.c 
> -L/opt/local/lib -ltiff -L/opt/local/lib -ljpeg -L/opt/local/lib -lpng 
> -L/opt/local/lib -lz -L/opt/local/libexec/jasper2/lib -ljasper 
> -L/usr/X11R6/lib -lX11 -lm
>:info:build xvjp2k.c:77:5: error: redefinition of 'jas_getdbglevel'
>:info:build int jas_getdbglevel(void) {return 0;}
>:info:build ^
>:info:build /opt/local/include/jasper/jas_debug.h:123:5: note: previous 
> definition is here
>:info:build int jas_getdbglevel(void)
>:info:build ^
>:info:build 1 error generated.
>:info:build make: *** [xvjp2k.o] Error 1
> 
> Anyone else seeing this before I lodge a bug report?  I guess a dependency 
> must've changed to cause the rebuild...
> 
> -- Dave

Re: libgcc9 and other ports that will never build on my system

[Richard L. Hamilton]

> On Sep 12, 2022, at 3:18 PM, chilli.names...@gmail.com wrote:
> 
> Mostly got it. But what if there are two bad ports?
> 

That’s the

port upgrade outdated and not \( badport1 or badport2 \)

example. One could have three or more in there too, as far as that goes. The 
backslashes are not properly part of the syntax, but they are there to keep the 
shell from interpreting the parentheses.

In other words, you can have full blown Boolean expressions with and, or, not, 
and parentheses as complicated as you care to type, more or less. Terms like 
“outdated” can be regarded as roughly equivalent to a parenthesized list of 
whatever they expand to, if that makes any sense.


>> On Sep 12, 2022, at 15:16, Richard L. Hamilton  wrote:
>> 
>> You can say
>> 
>> port upgrade outdated and not badport1
>> 
>> or even
>> 
>> port upgrade outdated and not \( badport1 or badport2 \)
>> 
>> 
>> although if badport1 (badport2, etc) is depended on by something else being 
>> upgraded, it will probably get upgraded too (and fail, I suppose).
>> 
>> You can upgrade a port without upgrading what it depends on with
>> 
>> port -n upgrade outdated and not badport1
>> 
>> but AFAIK, that’s usually NOT recommended except more rarely and 
>> specifically than something as broad as port upgrade outdated, to work 
>> around a specific problem (for which I gather you should have checked for a 
>> ticket and if it didn’t exist already, filed one). Although if dependencies 
>> other than badport1 are also included in “outdated", I guess they’ll get 
>> updated too, if not necessarily in the ideal order.
>> 
>> although when I say that, I’m kind of saying do what I say and not what I 
>> do, because I wing it a bit just to get through the daily update ritual. My 
>> usual looks a bit like the line above with the parenthesized list of what 
>> not to update, except rather longer.
>> 
>> 
>>> On Sep 12, 2022, at 3:02 PM, chilli.names...@gmail.com wrote:
>>> 
>>> 
>>> Yes, you got it. How do I command MacPorts to upgrade all outdated ports 
>>> "and not" this whatever troublesome port?  Is there a way? If you just told 
>>> me, you'll have to be less subtle.
>>> 
>>>>> On Sep 12, 2022, at 14:00, Bill Cole 
>>>>>  wrote:
>>>> On 2022-09-12 at 12:04:41 UTC-0400 (Mon, 12 Sep 2022 12:04:41 -0400)
>>>> 
>>>> is rumored to have said:
>>>> 
>>>>> Thanks for catching that.
>>>>> 
>>>>> From my macports.conf file:
>>>>> # CPU architecture to target. Supported values are "ppc", "ppc64",
>>>>> # "i386", "x86_64", and "arm64". Defaults to:
>>>>> # - Mac OS X 10.5 and earlier: "ppc" on PowerPC, otherwise "i386".
>>>>> # - Mac OS X 10.6 - 10.15: "x86_64" on 64-bit Intel, otherwise "i386".
>>>>> # - macOS 11 and later: "arm64" on Apple Silicon, otherwise "x86_64".
>>>>> build_arch  x86_64
>>>>> 
>>>>> 
>>>>> thus, I was not trying to build for i386, I've specified x86_64
>>>> 
>>>> If for some reason you had built it with the 'universal' variant you could 
>>>> also end up rebuilding it for both. But as I said, I don't think this is 
>>>> the point of attack.
>>>> 
>>>>> I find it difficult to believe MacPorts has no control over what it is 
>>>>> updating.
>>>>> MacPorts upgrade command obviously has some way to know what ports have 
>>>>> updates available:
>>>>> 
>>>>> port upgrade outdated
>>>>> 
>>>>> The outdated argument tells upgrade what to update. I was hoping it would 
>>>>> be something simple like
>>>>> 
>>>>> port upgrade outdated -libgcc9
>>>> 
>>>> Like I said...
>>>> 
>>>> 
>>>>>>> On Sep 12, 2022, at 09:29, Bill Cole 
>>>>>>>  wrote:
>>>> [...]
>>>> 
>>>>>> 3. "sudo port upgrade outdated and not libgcc9" should work, but it will 
>>>>>> leave everything dependent on libgcc9 at older versions.
>>>> 
>>>> The only difference from your hypothetical command is 'and not' instead of 
>>>> '-'
>>>> 
>>>> 
>>>> -- 
>>>> Bill Cole
>>>> b...@scconsult.com or billc...@apache.org
>>>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>>>> Not Currently Available For Hire
>>> 
>> 
> 

Re: libgcc9 and other ports that will never build on my system

[Richard L. Hamilton]

You can say

port upgrade outdated and not badport1

or even

port upgrade outdated and not \( badport1 or badport2 \)


although if badport1 (badport2, etc) is depended on by something else being 
upgraded, it will probably get upgraded too (and fail, I suppose).

You can upgrade a port without upgrading what it depends on with

port -n upgrade outdated and not badport1

but AFAIK, that’s usually NOT recommended except more rarely and specifically 
than something as broad as port upgrade outdated, to work around a specific 
problem (for which I gather you should have checked for a ticket and if it 
didn’t exist already, filed one). Although if dependencies other than badport1 
are also included in “outdated", I guess they’ll get updated too, if not 
necessarily in the ideal order.

although when I say that, I’m kind of saying do what I say and not what I do, 
because I wing it a bit just to get through the daily update ritual. My usual 
looks a bit like the line above with the parenthesized list of what not to 
update, except rather longer.


> On Sep 12, 2022, at 3:02 PM, chilli.names...@gmail.com wrote:
> 
> 
> Yes, you got it. How do I command MacPorts to upgrade all outdated ports "and 
> not" this whatever troublesome port?  Is there a way? If you just told me, 
> you'll have to be less subtle.
> 
>> On Sep 12, 2022, at 14:00, Bill Cole 
>>  wrote:
>> On 2022-09-12 at 12:04:41 UTC-0400 (Mon, 12 Sep 2022 12:04:41 -0400)
>> 
>> is rumored to have said:
>> 
>>> Thanks for catching that.
>>> 
>>> From my macports.conf file:
>>> # CPU architecture to target. Supported values are "ppc", "ppc64",
>>> # "i386", "x86_64", and "arm64". Defaults to:
>>> # - Mac OS X 10.5 and earlier: "ppc" on PowerPC, otherwise "i386".
>>> # - Mac OS X 10.6 - 10.15: "x86_64" on 64-bit Intel, otherwise "i386".
>>> # - macOS 11 and later: "arm64" on Apple Silicon, otherwise "x86_64".
>>> build_arch  x86_64
>>> 
>>> 
>>> thus, I was not trying to build for i386, I've specified x86_64
>> 
>> If for some reason you had built it with the 'universal' variant you could 
>> also end up rebuilding it for both. But as I said, I don't think this is the 
>> point of attack.
>> 
>>> I find it difficult to believe MacPorts has no control over what it is 
>>> updating.
>>> MacPorts upgrade command obviously has some way to know what ports have 
>>> updates available:
>>> 
>>> port upgrade outdated
>>> 
>>> The outdated argument tells upgrade what to update. I was hoping it would 
>>> be something simple like
>>> 
>>> port upgrade outdated -libgcc9
>> 
>> Like I said...
>> 
>> 
 On Sep 12, 2022, at 09:29, Bill Cole 
  wrote:
>> [...]
>> 
 3. "sudo port upgrade outdated and not libgcc9" should work, but it will 
 leave everything dependent on libgcc9 at older versions.
>> 
>> The only difference from your hypothetical command is 'and not' instead of 
>> '-'
>> 
>> 
>> -- 
>> Bill Cole
>> b...@scconsult.com or billc...@apache.org
>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>> Not Currently Available For Hire
> 

Re: ftp client

[Richard L. Hamilton]

If you can’t avoid ftp, gftp in inetutils is I think the usual GNU version, 
which is okay. Or curl can do a single transfer or transfer matching a pattern 
on a single command line, which would be easier to script than traditional ftp 
clients - but NOT for ease of use in the usual sense.

Cyberduck (not in MacPorts) is a nice GUI ftp that can handle a number of other 
file transfer situations too. And of course Finder with the aid of a 
system-supplied ftp filesystem can also do ftp.

All depends on what you want.


> On Aug 24, 2022, at 2:24 PM, Mark Brethen  wrote:
> 
> What’s the recommended ftp client nowadays for ease of use? There are too 
> many to list from 'port search'. I intend to use it with qemu between 
> host/guest. 
> 
> Thanks,
> Mark

Re: Why so many gcc updates in the last week or so?

[Richard L. Hamilton]

Ok, thanks. If I see another one in the next day or two, I’ll just add gcc12 
and libgcc12 to my do-not-update list (which if non-empty, is used to generate 
“and not \( line1 or line2 … \)” to append to a "port upgrade outdated" 
command). Since my update procedures are halfway between manual and automatic 
(issuing the initial commands and leaving me to deal interactively with 
oddities if any, rather than notifying me after-the-fact) for two non-windows 
batches (22 systems first batch, 4 systems 2nd batch - don’t want too many VMs 
on any given host running at once), that’s the least ugly thing for me to do, 
provided I remember to take those entries out when things stabilize.


> On Jul 21, 2022, at 5:20 AM, Chris Jones  wrote:
> 
> 
> Gcc12 brought a number of issues, that took time to be solved and required a 
> number of updates in other gcc versions as well, and only became apparent as 
> users submitted tickets etc. for those issues as they where found. I 
> apologies for the number of updates, but I think now, touch wood, things will 
> stabilize.
> 
> If you want to avoid having to build from source large updates, just hold off 
> doing them until you see the binary tarballs are available, e.g. at
> 
> https://packages.macports.org/gcc12/
> 
> Chris
> 
> On 21/07/2022 10:12 am, Richard L. Hamilton wrote:
>> It seems there have been updates for one version or multiple versions of gcc 
>> or their libraries nearly every day lately. What’s up with that?
>> If one has to recompile (some are prebuilt, thankfully), that REALLY slows 
>> down updates. With 7 systems (4 of which are VMs at different macOS 
>> versions), anything that makes updates slower is not fun. Not to mention 
>> about 22 Linux, Solaris, or Windows systems (mostly VMs/LDOMs/zones, not 
>> physical boxes! not nearly as much hardware as it sounds like) getting 
>> updated too. (nostalgia for decades of being in IT, and that doesn’t even 
>> count emulators for Apollo workstation, IBM mainframe, and other exotica 
>> distantly remembered)
> 

Why so many gcc updates in the last week or so?

[Richard L. Hamilton]

It seems there have been updates for one version or multiple versions of gcc or 
their libraries nearly every day lately. What’s up with that?

If one has to recompile (some are prebuilt, thankfully), that REALLY slows down 
updates. With 7 systems (4 of which are VMs at different macOS versions), 
anything that makes updates slower is not fun. Not to mention about 22 Linux, 
Solaris, or Windows systems (mostly VMs/LDOMs/zones, not physical boxes! not 
nearly as much hardware as it sounds like) getting updated too. (nostalgia for 
decades of being in IT, and that doesn’t even count emulators for Apollo 
workstation, IBM mainframe, and other exotica distantly remembered)

coreutils and findutils +universal configure problem on Snow Leopard

[Richard L. Hamilton]

coreutils and findutils +universal now may have a problem configuring where 
that includes 32-bit, specifically seen on Snow Leopard
(due to cranky Internet, I'm a few days behind, so that might have happened 
anywhere in the last week+)

:info:configure configure: error: in 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_coreutils/coreutils/work/coreutils-9.1':
:info:configure configure: error: The 'time_t' type stops working after January 
2038,
:info:configureand your system appears to support a wider 
'time_t'.
:info:configureTry configuring with 
'CC="/opt/local/bin/clang-mp-8.0 -m64"'.
:info:configureTo build with a 32-bit time_t anyway (not 
recommended),
:info:configureconfigure with '--disable-year2038'.
:info:configure See `config.log' for more details

ticket #65457 filed


and

:info:configure configure: error: in 
`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_findutils/findutils/work/findutils-4.9.0-i386':
:info:configure configure: error: The 'time_t' type stops working after January 
2038,
:info:configureand your system appears to support a wider 
'time_t'.
:info:configureTry configuring with 
'CC="/opt/local/bin/clang-mp-8.0 -m64"'.
:info:configureTo build with a 32-bit time_t anyway (not 
recommended),
:info:configureconfigure with '--disable-year2038’.

ticket #65458 filed

Re: Warning: Error parsing file...

[Richard L. Hamilton]

> On Jul 3, 2022, at 6:38 PM, Michael Newman via macports-users 
>  wrote:
> 
> 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
> 


port provides /opt/local/bin/msgcmp /opt/local/bin/msgcomm

will reveal that both files were provided by the port gettext.

So forcibly update the port

sudo port upgrade -n --force gettext

and that should fix those files. 

Re: MacPorts bind9 dig not working correctly

[Richard L. Hamilton]

Looking at both with Wireshark, it looks like both send the query (and the 
Ethernet packet in both cases appears to be multicast, as it should be) and get 
the response. But it seems the MacPorts one doesn’t “hear” the response.

Looking at dtruss output for both, it looks like the Apple version issues some 
recvmsg() system calls (presumably thus receiving the response), but the 
MacPorts version never does. Without looking at the source, I couldn’t say why 
it never gets there; and even looking at it, I might not, given that I’m not 
familiar with the bind9 code, and it looks like it might be a bit hard to 
follow.

> On Jun 25, 2022, at 11:56 PM, Larry Stone  wrote:
> 
> dig +short @224.0.0.251 -p 5353 hostname.local

Re: Mixing brew and macports

[Richard L. Hamilton]

Brew installs into /usr/local which can if it duplicates files (esp. libraries 
or header files) in MacPorts, cause problems, because apparently not all tools 
MacPorts must use for building can be persuaded to ignore /usr/local in their 
search for files - so they might find and use the wrong version.

That said, you may get away with a LITTLE of it without too much problem; I 
have, so far. :-)


> On Jun 7, 2022, at 4:20 AM, Christoph Kukulies  wrote:
> 
> I’m not sure whether I can harmlessly use brew to install a package that is 
> not available under macports, to be precise, sigrok/pulseview is the target.
> 
> All available remedies refer to using brew install.
> 
> May I use brew along with macports, the latter being my tool of choice for 
> maintaining external software packages for macOS?
> 
> —
> Christoph
> 
> 

Re: Should I expect a +quartz variant to propagate to dependencies, and overrule existing variants?

[Richard L. Hamilton]

The x11 (and perhaps quartz) variants do not all behave similarly.

ffmpeg is a command line program for conversions and filtering of audio and 
video; it just has an optional ability to display video, but only on x11;  
presumably nobody ever wrote a quartz display alternative for it. But some 
quartz program that was simply using ffmpeg for conversions and not for 
display, could do so regardless of that.

Some ports may be able to be built with both +x11 and +quartz; but with others, 
those may be mutually exclusive or one might be missing.

Since ports originate as separate projects from separate creators, anything 
that the packaging into MacPorts does to make them APPEAR more uniform is a 
somewhat fragile illusion - meaning that to some degree or another (perhaps 
even with the new/ongoing alternative to variants) one sometimes has to know 
more than one might wish to about how it all works. In routine cases, the 
illusion might be helpful, but when going beyond the defaults, you may have to 
know more.

That can also be the case when one tries to manage a bunch of very different 
systems (Windows, macOS, Linux of various distros, etc, and not all of each 
even of the same version); one can build tools that in the routine case hide 
some differences, but when things get interesting, one still needs to look at 
the fake wizard behind the screen.

> On Jun 5, 2022, at 1:42 PM, Jim DeLaHunt  wrote:
> 
> Thank you for the reply, Ryan. This is very helpful.
> 
> On 2022-06-02 19:33, Ryan Schmidt wrote:
>> On Jun 1, 2022, at 17:31, Jim DeLaHunt wrote:
>> 
>>> Should I expect a +quartz variant to propagate to dependencies, and 
>>> overrule existing variants?
>> Variants specified on the command line when installing a port propagate to 
>> any dependencies that have not yet been installed. They do not propagate to 
>> any dependencies that have already been installed.
> 
> That is good to know, thanks.
> 
> I looked at the Guide to see if this behaviour was described. In my opinion 
> it is not described adequately. I've opened a ticket against the Guide, " 
> Guide 3.2.1: Say that variant specification on port install does not overrule 
> existing ports" .
> 
> 
>> You can add a variant to an already-installed port by using "sudo port 
>> upgrade --enforce-dependencies someport +somevariant".
> 
> Clever!  I see that this is documented in 
> . I had not noticed that. I 
> guess I have not read the Guide diligently.
> 
> 
>>> …Thus I succeeded in fumbling my way through installing gimp +quartz 
>>> despite dependencies already present with the wrong variants, but it was a 
>>> bit messy and confusing. Should I expect MacPorts to do a better job with 
>>> this situation?  If so, maybe I should file a ticket against some of these 
>>> ports, to see if portfile changes would avoid the problems.
>> This undesirable experience is why we recommend users choose whether to use 
>> +x11 or +quartz before installing any ports, or uninstall all ports and 
>> reinstall them if changing one's mind after having installed ports.
> 
> Interesting! Where is this advice documented? I certainly did not know it 
> before. (But them, I guess I have not read the Guide diligently.) The place 
> where these instructions would have done me good is in the Migration 
> instructions: .
> 
> I just looked. I have 27 ports with +x11 variants specified. 4 of those ports 
> have +quartz+x11: cairo, cairomm, pango, pangomm. For all 4 of them, +x11 and 
> +quartz appear to be default variants, so I suppose they can coexist. But 
> that leaves me with 23 ports with +x11 to deal with. At least some of them 
> (e.g. ffmpeg) have no +quartz variant. Can such ports coexist as +x11 
> variants with the rest of a collection of +quartz variant ports?
> 
> I see my port gtk3 is installed as +x11 but not as +quartz. I suspect that is 
> not what I want. Thank you for the heads-up.
> 
> Thank you again for the explanation. Best regards,
> —Jim DeLaHunt
> 
> 

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

[Richard L. Hamilton]

Would use of @loader_path as in @loader_path/../lib or whatever when linking 
binaries (and something similar for linking between libraries within MacPorts) 
not be a big part of  making it so the executables and libraries didn't embed 
where the tree lived? There would doubtless be other changes to make it 
possible  to move /opt/local without breaking pre-built binaries, but that 
might be a big part of  it. And it could be started one port at a time, long 
before everything needed to be done to make that possible.

Not sure how executables and frameworks within app bundles in e.g. 
/Applications/MacPorts could be handled with that.

> On Apr 14, 2022, at 05:48, Ryan Schmidt  wrote:
> 
> On Apr 14, 2022, at 04:34, Peter Serocka wrote:
> 
>> Sure. On the other hand -- let me suggest MacPorts to adopt 
>> OS/architecture-specific prefixes by default. Transitions will benefit, in 
>> particular in cases where "some" ports are troublesome.
> 
> I don't think there's any chance of that happening now. MacPorts has used the 
> /opt/local prefix for 20 years and I think you're the first person in that 
> time to suggest changing it. There are many projects out there, and many web 
> pages with documentation, that are already written with that prefix in mind.
> 
> Even if we thought it would be a good idea to change it, if we wanted to 
> change it for any existing users, we would have to develop an upgrade 
> strategy for it. And we would have to recompile all of the binary archives we 
> offer.
> 
> Migrating to a new OS version or architecture would then become more 
> complicated, as users would need to manually move configuration files and 
> other data from one prefix to another.
> 
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: port diagnose and xcode

[Richard L. Hamilton]

MacPorts is by nature not just one thing. There's the "port" command, related 
commands, the  structure of Portfiles; there's the servers that deliver up both 
pre-built executables AND whether for lack of capacity to pre-build or because 
certain ports need to be locally built, may also deliver packaged source that 
builds locally. All of that and maybe more is MacPorts itself.

And then there's the individual ports. Those are maintained (or sometimes not) 
by different people, and very dependent on the "upstream" supplier of the 
project, who may not always accept patches specific to make it work on a Mac 
(let alone older macOS versions), so that port may have to have and apply its 
own patches, which adds delay between upstream update and port update.

Even IF there was one vision of what MacPorts should do, that's quite a lot and 
although it really tries, CANNOT guarantee consistent results on everything for 
everyone - nothing can, and esp. nothing with mostly unpaid volunteers can 
(although I think Apple provides the servers).

Taking all that into account (and I'm NOT part of the "team" just another user, 
so some of that may not be 100% accurate), you might consider clarifying just 
what you want.

Doubtless brew and fink also have some difficulties getting everything just 
right (modulo different opinions of what "just right" might be). So you might 
find that you'll NEVER be happy. If that turns out to be the case, it might be 
your expectations rather than anyone else's performance needs to be 
re-evaluated.

> On Mar 27, 2022, at 09:25, Michele Venturi  wrote:
> 
> That's what I said and anyway I repeat for the nth time
> to people that doesn't want to know it: it's YOUR stuff,
> YOU should know what it is, I'm not here to tell you what
> to do you with it, this just a friendly reminder to decide...
> 
> Il dom 27 mar 2022, 01:42 Ryan Schmidt  > ha scritto:
> On Mar 26, 2022, at 00:48, Michele Venturi wrote:
> 
> > As usual this project too is a mess because everyone has a different idea 
> > of what it is,has been and will be.
> 
> If you have constructive criticism for changes that should be made, feel free 
> to start discussions about them. Otherwise you may be happier using something 
> else.
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: port diagnose and xcode

[Richard L. Hamilton]

Is there a way one can see by examining Portfiles (ideally something that could 
be scanned for with e.g. a perl script), or preferably, with some "port" 
command, which ports require command line tools vs Xcode vs neither (albeit 
perhaps needing something to get a compiler port installed)?

> On Mar 12, 2022, at 21:47, Ryan Schmidt  wrote:
> 
> On Mar 11, 2022, at 02:02, Michele Venturi wrote:
> 
>> What is wrong is that a simple package manager
>> requires an entire multigigabyte professional IDE;
>> I have even taken the time to talk to them about it
>> and file a bug about it,but they clearly don't care...
>> It's surely not a new issue,it's like that by design...
> 
> MacPorts does not require Xcode.
> 
> Compiling ports requires a compiler and associated files. In most cases the 
> Xcode command line tools are sufficient. A small number of ports cannot build 
> with the CLT and require the full Xcode install. If you try to compile one of 
> these ports and you do not have Xcode installed, you should see a message 
> telling you to install Xcode.
> 
> In many cases, we have already built binaries of ports that MacPorts on your 
> computer will automatically use. In those cases, you do not need a compiler 
> -- you do not need Xcode nor do you need the Xcode command line tools.
> 
> It was recently suggested that our documentation is not clear enough on these 
> points and I believe someone was going to make improvements.
> 
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: IRC channel

[Richard L. Hamilton]

Thanks - although for anyone else trying to get that to work, it looks like 
it's libera.chat (with the "e").

LimeChat obviously hates me, but eventually I figured it out enough that it 
works, although I used a command line client first to try (and to register my 
nickname).

> On Mar 6, 2022, at 06:40, Marius Schamschula  wrote:
> 
> Freenode is dead, not just for #macports.
> 
> However, #macports irc is now at libra.chat
> 
> I’ll ping the channel.
> 
> Marius
> --
> Marius Schamschula
> 
> 
> 
> 
>> On Mar 6, 2022, at 3:50 AM, Richard L. Hamilton > <mailto:rlha...@smart.net>> wrote:
>> 
>> The #macports channel exists (I connected to freenode using LimeChat, but 
>> that was just the app I had already and the first server I recognized); 
>> there appear to be some people on it, but no activity right now - maybe they 
>> stay connected even when they're asleep, I don't know. I don't recall ever 
>> using it, nor probably even having used IRC in quite a few years; I'd nearly 
>> forgotten how to use it.
>> 
>> update: however, the web interface at chat.macports.org 
>> <http://chat.macports.org/> seems to get "internal server error" (yes, I was 
>> already logged into GitHub), at least using Safari.
>> 
>>> On Mar 6, 2022, at 02:19, Michele Venturi >> <mailto:dard...@gmail.com>> wrote:
>>> 
>>> Is it still available?
>> 
>> -- 
>> eMail:   mailto:rlha...@smart.net 
>> <mailto:rlha...@smart.net>
>> 
>> 
>> 
>> 
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: IRC channel

[Richard L. Hamilton]

The #macports channel exists (I connected to freenode using LimeChat, but that 
was just the app I had already and the first server I recognized); there appear 
to be some people on it, but no activity right now - maybe they stay connected 
even when they're asleep, I don't know. I don't recall ever using it, nor 
probably even having used IRC in quite a few years; I'd nearly forgotten how to 
use it.

update: however, the web interface at chat.macports.org seems to get "internal 
server error" (yes, I was already logged into GitHub), at least using Safari.

> On Mar 6, 2022, at 02:19, Michele Venturi  wrote:
> 
> Is it still available?

-- 
eMail:  mailto:rlha...@smart.net

Re: C API for ACLs

[Richard L. Hamilton]

Use the source, Luke.

How "ls" does it:

https://github.com/apple-oss-distributions/file_cmds/tree/file_cmds-321.100.11/ls

Looks like the presence of an ACL and getting a handle for it is done in ls.c, 
and actually retrieving and printing all the entries (ls.c retrieves the 1st 
entry just to make sure it's really there) is done in print.c.

I gather that getattrlist(2) and setattrlist(2) are what, for the filesystems 
that support those calls (not all do!) underlie the various section 3 acl*() 
routines, but if in doubt, you could even look at the source for those library 
routines. But beware: acl(3) says:
 The syscalls between the internal interfaces and the public library 
routines may change over time, and as such are not documented.  They are not 
intended to be called directly without going through the library.

> On Feb 5, 2022, at 22:29, raf  wrote:
> 
> Hi,
> 
> Does anyone know how to get at macOS's ACLs from C?
> I just need to access them in text form. I'm using
> the "POSIX" ACL API, and it compiles and runs, but
> it doesn't find anything. The ACL entries that I can
> create with chmod +a, and view with ls -e, don't
> show up because they're not "POSIX" ACL compatible
> (or some similar sensible reason). Searching the net
> has only turned up the "POSIX" ACL API so far.
> 
> cheers,
> raf
> 

-- 
eMail:  mailto:rlha...@smart.net






smime.p7s
Description: S/MIME cryptographic signature

Re: openat on 10.6.8?

[Richard L. Hamilton]

Pretty sure it first appeared in 10.10, that's the first one for which I see 
the man page in the OS source code.

Implementations lag behind standards, although admittedly that's a rather 
substantial lag. :-)

(I've downloaded quite a number of versions of the source, and for each built 
an index file listing the name of each .tar.gz file along with each file within 
it, so a simple grep can find some things quickly, although in this case I had 
to also grep for xnu, to keep the search from picking up things like gnutar 
that optionally _used_ openat)

> On Jan 29, 2022, at 20:59, raf  wrote:
> 
> Hi,
> 
> I just tried to compile (/usr/bin/cc) something (not a
> port) that uses openat(2) on 10.6.8 (with current
> macports and Xcode 3.2.6 (1761)) but it wasn't there. I
> expected it to be, because openat() was standardized by
> 2008 and the 10.6.8 system is from 2010. Did I compile
> it wrong (e.g., old default compiler), or did openat()
> just not appear until a later version of macOS?
> 
> cheers,
> raf
> 

-- 
eMail:  mailto:rlha...@smart.net






smime.p7s
Description: S/MIME cryptographic signature

Re: Understaning rleaves, rdepof

[Richard L. Hamilton]

I don't have dovecot installed on any macOS (I actually  have it on Solaris 11 
on a T5240 (!) obtained via eBay, but not yet set up), so I can't re-create 
that.

But looking at the dovecot Portfile, it seems the dependency on apache-solr8 is 
specific to the +solr variant (which you have, to be sure). So assuming your 
installation isn't a bit confused somehow, maybe port isn't always smart about 
showing variant-specific dependencies.

That's just a guess, though; I'm not nearly good enough with Tcl to understand 
the "port" code in any reasonable amount of time.

You do have apache-solr8 installed, right? (it's also possible to get 
dependency information for ports not installed, i.e. I can do "port echo 
rdepof:dovecot" even though I don't have dovecot installed) 

> On Jan 29, 2022, at 10:52, Gerben Wierda  wrote:
> 
> Thank you. That solves a lot of the mystery. I did encounter a small mystery:
> 
> gerben@hermione ~ % port installed rdepof:dovecot 
> The following ports are currently installed:
>   autoconf @2.71_1 (active)
>   automake @1.16.5_0 (active)
>   bison @3.8.2_2 (active)
>   bison-runtime @3.8.2_0 (active)
>   bzip2 @1.0.8_0 (active)
>   flex @2.6.4_0 (active)
>   gettext @0.21_0 (active)
>   gettext-runtime @0.21_0 (active)
>   gettext-tools-libs @0.21_0 (active)
>   libiconv @1.16_1 (active)
>   libtextstyle @0.21_0 (active)
>   libtool @2.4.6_13 (active)
>   lz4 @1.9.3_1 (active)
>   m4 @1.4.19_1 (active)
>   ncurses @6.3_0 (active)
>   openssl @3_2 (active)
>   openssl3 @3.0.1_0+legacy (active)
>   pkgconfig @0.29.2_0 (active)
>   xz @5.2.5_0 (active)
>   zlib @1.2.11_0 (active)
> gerben@hermione ~ % port installed rdependentof:apache-solr8
> The following ports are currently installed:
>   dovecot @2.3.17_0+apns+solr (active)
> 
> Or, it seems port knows apache-solr8 is requested by dovecot but not the 
> other way around.
> 
> Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
> R IT Strategy <https://ea.rna.nl/> (main site)
> Book: Chess and the Art of Enterprise Architecture 
> <https://ea.rna.nl/the-book/>
> Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>
> 
>> On 29 Jan 2022, at 14:31, Richard L. Hamilton > <mailto:rlha...@smart.net>> wrote:
>> 
>> You're using it wrong. Try for example
>> 
>> port installed rdepends:xorg-libx11
>> 
>> Note the colon (no spaces) between depends and the port name. Same for 
>> depends, depof, rdepof, and others; see the port man page for details.
>> 
>>> On Jan 29, 2022, at 07:20, Gerben Wierda via macports-users 
>>> >> <mailto:macports-users@lists.macports.org>> wrote:
>>> 
>>>> On 29 Jan 2022, at 11:45, Gerben Wierda via macports-users 
>>>> >>> <mailto:macports-users@lists.macports.org>> wrote:
>>>> 
>>>> I was cleaning up MacPorts on one system prior to an OS upgrade, and I 
>>>> noticed
>>>> 
>>>> root@hermione LaunchDaemons # port list rleaves  
>>>> root@hermione LaunchDaemons # port list rdepof xorg-libX11
>>>> xorg-libX11@1.7.2  x11/xorg-libX11
>>>> 
>>>> Now, as I understand it rleaves are the ports that are in your landscape 
>>>> that have nothing that depends on it. Accoriding to port there are no such 
>>>> ports. So, the port xorg-libX11 should have some sort of a dependency. But 
>>>> all my attempts to find it come up empty.
>>>> 
>>>> Cleaning up MacPorts remains a mystery to me. 
>>> 
>>> Adding to my confusion:
>>> 
>>> albus:MacPortsDev sysbh$ port installed depof dovecot
>>> The following ports are currently installed:
>>>   dovecot @2.3.17_0+apns+solr (active)
>>> albus:MacPortsDev sysbh$ port installed rdepof dovecot
>>> The following ports are currently installed:
>>>   dovecot @2.3.17_0+apns+solr (active)
>>> albus:MacPortsDev sysbh$ port installed rdepends dovecot
>>> The following ports are currently installed:
>>>   dovecot @2.3.17_0+apns+solr (active)
>>> albus:MacPortsDev sysbh$ port installed dependentof dovecot
>>> The following ports are currently installed:
>>>   dovecot @2.3.17_0+apns+solr (active)
>>> albus:MacPortsDev sysbh$ port installed rdependentof dovecot
>>> The following ports are currently installed:
>>>   dovecot @2.3.17_0+apns+solr (active)
>>> 
>>> Same for postfix for instance. Now, whatever pseudo-portname I give, the 
>>> answer is always only the port itself. That cannot be right.
>>> 
>>>> Gerben Wierda (LinkedIn <https://www.linkedin.com/in/gerbenwierda>)
>>>> R IT Strategy <https://ea.rna.nl/> (main site)
>>>> Book: Chess and the Art of Enterprise Architecture 
>>>> <https://ea.rna.nl/the-book/>
>>>> Book: Mastering ArchiMate <https://ea.rna.nl/the-book-edition-iii/>
>> -- 
>> eMail:   mailto:rlha...@smart.net 
>> <mailto:rlha...@smart.net>
>> 
>> 
>> 
>> 
> 

-- 
eMail:  mailto:rlha...@smart.net






smime.p7s
Description: S/MIME cryptographic signature

Re: Warning: The macOS 12 SDK does not appear to be installed. Ports may not build correctly.

[Richard L. Hamilton]

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



> On Jan 29, 2022, at 07:46, Gerben Wierda via macports-users 
>  wrote:
> 
> On a freshly updated macOS Monterey (Xcode updated, xcode-select install has 
> run (but reported it was already installed) I get warnings that the macOS 12 
> SDK has not been installed on some ports, e.g.:
> 
> --->  Computing dependencies for tiff
> --->  Fetching archive for tiff
> --->  Attempting to fetch tiff-4.3.0_0.darwin_21.x86_64.tbz2 from 
> https://packages.macports.org/tiff 
> --->  Attempting to fetch tiff-4.3.0_0.darwin_21.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/tiff 
> --->  Installing tiff @4.3.0_0
> --->  Activating tiff @4.3.0_0
> --->  Cleaning tiff
> Warning: The macOS 12 SDK does not appear to be installed. Ports may not 
> build correctly.
> Warning: You can install it as part of the Xcode Command Line Tools package 
> by running `xcode-select --install'.
> --->  Computing dependencies for xorg-xcb-proto
> --->  Dependencies to be installed: autoconf m4 automake python38 openssl
> --->  Fetching archive for m4
> --->  Attempting to fetch m4-1.4.19_1.darwin_21.x86_64.tbz2 from 
> https://packages.macports.org/m4 
> --->  Attempting to fetch m4-1.4.19_1.darwin_21.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/m4 
> --->  Installing m4 @1.4.19_1
> --->  Activating m4 @1.4.19_1
> --->  Cleaning m4
> 
> --->  Fetching archive for unbound
> --->  Attempting to fetch unbound-1.14.0_0.darwin_21.x86_64.tbz2 from 
> https://packages.macports.org/unbound 
> --->  Attempting to fetch unbound-1.14.0_0.darwin_21.x86_64.tbz2.rmd160 from 
> https://packages.macports.org/unbound 
> --->  Installing unbound @1.14.0_0
> --->  Activating unbound @1.14.0_0
> --->  Cleaning unbound
> Warning: The macOS 12 SDK does not appear to be installed. Ports may not 
> build correctly.
> Warning: You can install it as part of the Xcode Command Line Tools package 
> by running `xcode-select --install'.
> --->  Computing dependencies for xorg-libxcb
> 
> No idea why these give the warning and also not clear to me for which port 
> the warning actually holds (i.e. ‘Cleaning tiff’ or 'Computing dependencies 
> for xorg-xcb-proto’)
> 
> Gerben Wierda (LinkedIn )
> R IT Strategy  (main site)
> Book: Chess and the Art of Enterprise Architecture 
> 
> Book: Mastering ArchiMate 
> 

-- 
eMail:  mailto:rlha...@smart.net






smime.p7s
Description: S/MIME cryptographic signature

Re: Understaning rleaves, rdepof

[Richard L. Hamilton]

You're using it wrong. Try for example

port installed rdepends:xorg-libx11

Note the colon (no spaces) between depends and the port name. Same for depends, 
depof, rdepof, and others; see the port man page for details.

> On Jan 29, 2022, at 07:20, Gerben Wierda via macports-users 
>  wrote:
> 
>> On 29 Jan 2022, at 11:45, Gerben Wierda via macports-users 
>> > > wrote:
>> 
>> I was cleaning up MacPorts on one system prior to an OS upgrade, and I 
>> noticed
>> 
>> root@hermione LaunchDaemons # port list rleaves  
>> root@hermione LaunchDaemons # port list rdepof xorg-libX11
>> xorg-libX11@1.7.2  x11/xorg-libX11
>> 
>> Now, as I understand it rleaves are the ports that are in your landscape 
>> that have nothing that depends on it. Accoriding to port there are no such 
>> ports. So, the port xorg-libX11 should have some sort of a dependency. But 
>> all my attempts to find it come up empty.
>> 
>> Cleaning up MacPorts remains a mystery to me. 
> 
> Adding to my confusion:
> 
> albus:MacPortsDev sysbh$ port installed depof dovecot
> The following ports are currently installed:
>   dovecot @2.3.17_0+apns+solr (active)
> albus:MacPortsDev sysbh$ port installed rdepof dovecot
> The following ports are currently installed:
>   dovecot @2.3.17_0+apns+solr (active)
> albus:MacPortsDev sysbh$ port installed rdepends dovecot
> The following ports are currently installed:
>   dovecot @2.3.17_0+apns+solr (active)
> albus:MacPortsDev sysbh$ port installed dependentof dovecot
> The following ports are currently installed:
>   dovecot @2.3.17_0+apns+solr (active)
> albus:MacPortsDev sysbh$ port installed rdependentof dovecot
> The following ports are currently installed:
>   dovecot @2.3.17_0+apns+solr (active)
> 
> Same for postfix for instance. Now, whatever pseudo-portname I give, the 
> answer is always only the port itself. That cannot be right.
> 
>> Gerben Wierda (LinkedIn )
>> R IT Strategy  (main site)
>> Book: Chess and the Art of Enterprise Architecture 
>> 
>> Book: Mastering ArchiMate 
-- 
eMail:  mailto:rlha...@smart.net






smime.p7s
Description: S/MIME cryptographic signature

Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?

[Richard L. Hamilton]

> On Jan 22, 2022, at 11:13, Ryan Schmidt  wrote:
> 
> 
> 
> On Jan 22, 2022, at 09:36, Richard L. Hamilton wrote:
> 
>> I have no idea of the difficulty of such a change, but it would be 
>> interesting if Portfiles contained a release date, and the database of 
>> installed ports had both a copy of that for any given installed version, and 
>> perhaps the date of installation.
> 
> The registry stores installation dates.
> 
> $ port -v installed zlib
> The following ports are currently installed:
>  zlib @1.2.11_0 (active) requested_variants='' platform='darwin 19' 
> archs='x86_64' date='2021-11-12T12:14:43-0600'
>   
>
> 
> 
> Release date information is not available in MacPorts. Are you proposing that 
> the maintainer of every port should do research to discover the release date 
> every time they want to update a port to a new version and add that 
> information to a new field in the portfile? Why?
> 
> Or are you referring to the date when an update of a portfile was committed 
> to GitHub? If so, why would that be useful to you?

The latter, since the former, although possibly more useful, is too difficult.

Ideally, one has active the latest available version of a port, esp. given 
dependencies. But that doesn't always build, nor even always fail on first use 
after being built. Some might wish to let stuff age a bit for stability's sake, 
but not excessively, and dates might help with that.

A possible alternative: a reasonably easy way to keep only the most recent X 
inactive versions of a port with a given set of variants. That way one could 
keep things reasonably clean but have something to fall back to. If there's a 
non-manual way to do that (short of a creative script that digests the output 
of "port installed"), I must have missed it.



smime.p7s
Description: S/MIME cryptographic signature

Re: What have I forgotten about specifying which Perl should be /opt/local/bin/perl?

[Richard L. Hamilton]

I have no idea of the difficulty of such a change, but it would be interesting 
if Portfiles contained a release date, and the database of installed ports had 
both a copy of that for any given installed version, and perhaps the date of 
installation.

> On Jan 22, 2022, at 10:22, Gabriel Rosenkoetter  wrote:
> 
> On 2022-01-22 09:14 EST, Ryan Schmidt wrote:
>> On Jan 22, 2022, at 01:15, Gabriel Rosenkoetter wrote:
>>> On 2022-01-22 01:28 EST, Kastus Shchuka wrote:
 $ port echo installed and perl5
 perl5  @5.26.1_0+perl5_28
 perl5  @5.28.3_0+perl5_28
 perl5  @5.28.3_0+perl5_30
>>> You see how this is at best confusing and at worst user-antagonistic, right?
>> I'm sorry you feel antagonized; I'm sure that was nobody's intention.
> 
> Wait, wait, I take the antagonistic part of that back, in light of your other 
> response:
> 
> On 2022-01-22 09:11 EST, Ryan Schmidt wrote:
> > You can use any action you want; it doesn't have to be echo. For example, 
> > typically you might want "port installed active".
> 
> This is the output I was looking for:
> 
> [15] (gr@wedge:~)% port installed active and perl5
> The following ports are currently installed:
>  perl5 @5.28.3_0+perl5_34 (active)
> [16] (gr@wedge:~)%
> 
> That is, it shows the perl5 port version as well as the "what Perl will I get 
> if I run `perl`" version.
> 
> After this discussion, I understand clearly which version means what in 
> there, and I see how the query language has been designed to be at least a 
> little friendly to the non-programmer.
> 
> (I think this is probably still a pretty steep learning curve for a new user, 
> but I don't have any better suggestions.)
> 
>> This is one of the aforementioned challenges/complexities with providing 
>> multiple versions of a port.
> 
> Heard.
> 
>> If we stick with multiple perl versions, and the perl5 port to create the 
>> symlinks, then maybe it would indeed help reduce some confusion to change 
>> the perl5 port's version to 1.0, or a MMDD date, or anything else that 
>> is not the version of one of the perl ports.
> 
> I realize that I just sent an email stating the opposite, and I maintain that 
> "1.0" is a bad idea (because it'll eventually climb to being confusingly 
> similar with actual Perl version numbers), but using a POSIX date sounds very 
> promising to me, and would avoid showing, as above, both "5.28.3" and 
> (something that expands to:) "5.34.0" applied to the same port at the same 
> time.
> 
> -- 
> Gabriel Rosenkoetter (he/him)
> g...@eclipsed.net

-- 
eMail:  mailto:rlha...@smart.net






smime.p7s
Description: S/MIME cryptographic signature

Re: Sms for text messages in macports

[Richard L. Hamilton]

Every cell phone provider, or at least just about every US cell phone provider, 
has an email to SMS gateway. It's free for someone sending email to it, not 
necessarily for the recipient. The problem is you have to know the provider for 
a given number, and AFAIK, there's no particularly easy way to do that 
automatically and scriptably (so you can generate an email address for the 
correct gateway). MMS gateways also exist, although the acceptable MIME types 
and size/complexity limits for attachments may be tedious to discover.

Alternatives: a service (some free for small volumes only) that can send SMS 
from a computer.  Or Asterisk plus extensions, to set yourself up a full VoIP 
PBX...except that will need some paid service too, to connect to. But it will 
do a lot more than just send (or receive) SMS, it could forward phone calls, 
with proper hardware interfaces drive either old fashioned or VoiP phones, etc. 
It looks like a lot of work and learning as well as expense, though, and really 
ought to have a dedicated server, too, although that's not absolutely necessary.

> On Jan 16, 2022, at 23:11, chilli.names...@gmail.com wrote:
> 
> Hope this isn't a dumb comment, but recently noticed on the aggregator an 
> article about sending sms using python.
> 
> https://news.ycombinator.com/item?id=29915412 
> 
> 
> Does MacPorts have any python at all? I'm kidding.
> 
> 
> 
>> On Jan 16, 2022, at 21:31, Ryan Schmidt  wrote:
>> 
>> On Jan 15, 2022, at 10:10, dan d. wrote:
>> 
>>> I did a search and found nothing.  Did I miss something?
>> 
>> Need more information. You would like to find software that allows you to 
>> send text messages? If so, that would probably be provided by some service 
>> that you would have to subscribe to, so you should find a service whose 
>> terms and pricing you agree with and then see what software they propose to 
>> use with that service.




smime.p7s
Description: S/MIME cryptographic signature

Re: certificate update for old Macs

[Richard L. Hamilton]

> On Jan 4, 2022, at 14:37, Michael  wrote:
> 
> 
> 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.


The file that the script downloads is a whole bunch of PEM files concatenated 
together. The script shows splitting that into separate files at the start 
lines. Once that's done,

for file in *.pem
do
openssl -x509 -in $file -text >$file.txt 
done

will convert them to something you can look at. But that's the easy part. 
Looking at them and making sense of them and investigating each of the 169 will 
take you a day or two, which is why I'm not going to say much more about it. 
Probably IF one used a more trusted set of root certificates for comparison, 
one could decide which were definitely ok and which needed further 
investigation, but automating all that would NOT BE FUN.

Arguably the best solution is to get ahold of the certificates bundled in the 
latest OS version and use those, but no doubt that's often easier said than 
done, although you can (given enough space) download the update image on your 
old hardware that cannot run it, and (given enough knowledge) dig those 
certificates out of the update image and get them into a form that you can then 
import into your old system.

Realistically a lot could be fixed by just using keychain access to look for 
expired root certificates, and then look through one of those stashes for their 
replacements. Again manually, unless you want to do some very creative 
automating. I'm not volunteering to kill days or more doing that!

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

Everything has to start somewhere. Usually that's with an OS or browser vendor 
that decides which root certificates to bundle. (Do you REALLY want one 
planetary certificate at the tip-top provided by the UN, with all subordinate 
certificate issuers (government OR commercial) rooted to that? It'd be 
possible, but it's probably better trusting a bunch of different folks than 
trusting one with absolute power to break everything.) -Site or personal 
certificates chain back to the issuer's certificate. There are FREE CERTIFICATE 
ISSUERS, but they have their own problems, chiefly no budget, so jumping all 
the auditing hoops (or even keeping their infrastructure reliable) needed to 
get OS and browser vendors to included them can be a problem for them. And old 
OSs and the older browser versions supported on them for browsers other than 
the one that comes with the OS, are not supported forever because nobody is 
getting paid to do that, so they don't get updates for expired certificates, 
new certificate issuers, etc.

Programmers and such gotta eat too, have a roof over their heads, etc. Some 
even have little kiddies to feed, which is hardly greed, not that there's any 
shortage of actual greed.

Probably that site with the bunch to download is fine, but I don't have access 
to a list of baddies, so I'm at best ambivalent about trusting it without more 
digging first than I'm likely to do. At most, I'd do it to make stuff that 
didn't matter work on an old system, but never run anything that could lose me 
$$ or compromise accounts on there - so I'd have root certificates but NOT 
iCloud keychain access enabled nor any account passwords, personal 
certificates, etc on it.

Re: certificate update for old Macs

[Richard L. Hamilton]

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.

> On Jan 3, 2022, at 13:30, m9411  wrote:
> 
> Have been testing this with good results on 10.4 ... 10.11 :
> 
> http://logi.wiki/index.php/Update_Certificates_in_Older_macOS 
> 
> 
> Rgds,
> /Bjarne.
> 
> -- 
> 
>> 3 jan. 2022 kl. 19:20 skrev Riccardo Mottola via macports-users 
>> > >:
>> 
>> Hi,
>> 
>> how to react best for Let's Encrypt expiration?
>> 
>> I have read here some suggestions, is there a recommended, proven way?
>> 
>> I have MacOS 10.5, 10.6, 10.7 but nothing newer, so I suppose the route of 
>> "getting it from a newer macOS" is no way for me (if something doesn't share 
>> it with me).
>> 
>> Other proven ways?
>> 
>> 
>> Thank you,
>> 
>> Riccardo
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: Xcode 13.2 from App Store problem reported

[Richard L. Hamilton]

https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2_1-release-notes
 
<https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2_1-release-notes>
 13.2.1 looks like it would fix that, and has a workaround for vulnerable log4j 
within Xcode (used as part of app store upload, I guess).

> On Dec 15, 2021, at 23:48, Richard L. Hamilton  wrote:
> 
> Apparently the developer download site (NOT Mac App store) version is ok. Not 
> that most of us are in a rush to update, but just in case...
> https://www.macrumors.com/2021/12/14/xcode-13-2-bug/ 
> <https://www.macrumors.com/2021/12/14/xcode-13-2-bug/>
> 

-- 
eMail:  mailto:rlha...@smart.net

Xcode 13.2 from App Store problem reported

[Richard L. Hamilton]

Apparently the developer download site (NOT Mac App store) version is ok. Not 
that most of us are in a rush to update, but just in case...
https://www.macrumors.com/2021/12/14/xcode-13-2-bug/ 

pwait?

[Richard L. Hamilton]

macOS does not have the "pwait" command that Linux and some other Unix versions 
have, which allows waiting on any process (not just a child), given the PID. 
There would definitely be uses for that, like dealing with a process that 
backgrounds itself when you wish it didn't, provided you have some way (if it 
writes a PID file, or if there would only be one instance, using pgrep) to get 
the PID of the backgrounded process.

Turns out FreeBSD has an implementation that uses the kqueue mechanism, which 
macOS has.

https://github.com/freebsd/freebsd-src/tree/master/bin/pwait 


The Makefile there is useless unless building as part of FreeBSD, but one can 
just

cc pwait.c -o pwait

and it will compile and work just fine. There's also a man page in the 
previously mentioned location.

Wishing for a port...bit ugly when you can't use the supplied Makefile. Sadly, 
not volunteering myself. :-/

Given a trick in altering the URL a bit (replace tree/master with trunk), one 
can fetch just that directory rather than the whole FreeBSD tree:

svn co https://github.com/freebsd/freebsd-src/trunk/bin/pwait 

Re: Use of java (specifically on older macOS)

[Richard L. Hamilton]

BTW, in Xcode.app bundle (12.4),
/Applications/Xcode.app/Contents/SharedFrameworks/ContentDeliveryServices.framework/Versions/A/itms/share/OSGi-Bundles/org.apache.logging.log4j.core-2.11.2.jar

I imagine that will be getting updated not long after they realize it's there.

> On Dec 12, 2021, at 22:02, Steven Smith  wrote:
> 
> Java figures out which version to use from JAVA_HOME or 
> /Library/Java/JavaVirtualMachines. Are you sure that’s not a MacPorts version?
> 
> My native macOS java binary runs the last LTS jdk from MacPorts:
> 
>> sudo -u solr /usr/bin/java -version
>> openjdk version "11.0.13" 2021-10-19
>> OpenJDK Runtime Environment Temurin-11.0.13+8 (build 11.0.13+8)
>> OpenJDK 64-Bit Server VM Temurin-11.0.13+8 (build 11.0.13+8, mixed mode)
> 
> 
> This is a simple path issue because `java` Is found in /usr/bin. If you want 
> to use a MacPorts-installed binary, set up your paths appropriately. I’m not 
> aware of any practical difference this would make.
> 
>> port provides 
>> /Library/Java/JavaVirtualMachines/openjdk11-temurin/Contents/Home/bin/java
>> /Library/Java/JavaVirtualMachines/openjdk11-temurin/Contents/Home/bin/java 
>> is provided by: openjdk11-temurin
> 
> 
> 
>> On Dec 12, 2021, at 18:19, Gerben Wierda via macports-users 
>>  wrote:
>> 
>> Which means that MacPorts solr8 runs using macOS native java and not one 
>> from MacPorts itself. I thought the MacPorts stuff was supposed to be fully 
>> independent (except for Xcode).
> 

-- 
eMail:  mailto:rlha...@smart.net

Any ports use log4j 2?

[Richard L. Hamilton]

CVE-2021-44228 sounds kinda scary!

-- 
eMail:  mailto:rlha...@smart.net

Re: is macports getting rusty?

[Richard L. Hamilton]

I would expect that the buildbots also need to satisfy dependencies, and thus, 
heavily-depended on builds would tend to be done earlier, regardless of whether 
or not they were large and slow; and if they are large and slow, they're 
arguably delaying the building of even more smaller ports that don't depend on 
them, which is not necessarily a gain.

If I'm right about ports being built also by the buildbots in dependency order, 
any further tweak to build order would likely have minimal benefits.

The real improvement would be more buildbots, but that would take either a way 
of trusting volunteer buildbots (and that they were managed properly to produce 
fully correct results, and quite possibly dedicated to the purpose to avoid 
anything that would conflict or interfere), or an actual budget, or donated 
servers and server farm space, power, cooling, etc. Another improvement might 
be more people qualified, trusted, and authorized to babysit the buildbots, 
and/or automatic tickets on failed builds, since if a build on a buildbot 
fails, it's either a problem with the buildbot or with the port itself; and in 
the latter case, those building themselves will also have the problem.

> On Nov 29, 2021, at 09:15, Bill Cole 
>  wrote:
> 
> On 2021-11-29 at 08:32:46 UTC-0500 (Mon, 29 Nov 2021 13:32:46 +)
> Chris Jones 
> is rumored to have said:
> 
>> If you find yourself during an port update building rust from source, either 
>> just let it finish, or if you don't want your machine tied up building rust 
>> for some period, just cancel the build and try again later on, as as others 
>> have pointed out eventually the buildbots will provide the binary tarball 
>> for it and thus you will just pick that once its available.
> 
> This raises a question that I cannot find a clear answer to:
> 
> How are builds prioritized on the buildbots?
> 
> I would hope that in an ideal world, some priority is given to large, slow, 
> and heavily-depended-upon builds. It's also easier to say that than to 
> actually implement it, but it would help address a real pain point in using 
> MacPorts.
> 
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: is macports getting rusty?

[Richard L. Hamilton]

It is _possible_ to write reliable, secure code in C or even assembler. But for 
large complex software, it's darn unlikely; there's too many ways to mess up, 
even for capable and meticulous programmers, and most, even if bright and 
useful, aren't _that_ good.

Rust is supposed to eliminate a number of common types of problems, while still 
producing efficient code. So of course more projects will adopt it, and rewrite 
at least critical parts to use it (or something similar).

MacPorts is mainly a collection of software from elsewhere, and the mechanisms 
to automate installation and updates. That does not provide any control over 
such decisions of individual projects; MacPorts can perhaps feed bug fixes back 
to projects, but they don't have to accept them, and would not be likely to 
listen to complaints about depending on rust because of how slow it is to update

Give the developers of rust itself a piece of your mind if you like, over how 
slow it is to compile. Good luck with that - I suspect to be THAT slow 
(although really? compiling a C compiler suite plus library isn't exactly fast 
either) they might be doing some things by brute force that they haven't got 
any other good way to do - like running a serious test suite, as just one 
example. And of course they're the ones that suffer most over how slow it is to 
compile, since they have to rebuild rust every time they want to test some 
seemingly minor change. So I suspect they're already doing what can to speed it 
up that they don't think sacrifices any other concern.

A better question might be why aren't you getting/using one of the pre-built 
binary packages? On https://packages.macports.org/rust/ 
 I see for the latest rust version:

rust-1.56.1_3.darwin_13.x86_64.tbz2 2021-11-24 11:01101M
rust-1.56.1_3.darwin_14.x86_64.tbz2 2021-11-24 15:46101M
rust-1.56.1_3.darwin_15.x86_64.tbz2 2021-11-24 17:20101M
rust-1.56.1_3.darwin_16.x86_64.tbz2 2021-11-24 14:04101M
rust-1.56.1_3.darwin_17.x86_64.tbz2 2021-11-24 14:01101M
rust-1.56.1_3.darwin_18.x86_64.tbz2 2021-11-24 15:54101M
rust-1.56.1_3.darwin_19.x86_64.tbz2 2021-11-24 15:52101M
rust-1.56.1_3.darwin_20.arm64.tbz2  2021-11-25 15:0694M
rust-1.56.1_3.darwin_20.x86_64.tbz2 2021-11-24 10:38100M
rust-1.56.1_3.darwin_21.arm64.tbz2  2021-11-24 08:1594M
rust-1.56.1_3.darwin_21.x86_64.tbz2 2021-11-29 05:47100M

Look at the dates: they don't get pre-built instantly, so if you're updating 
early, you won't benefit from the pre-built version. There also appears to be a 
single defined variant (+debug) - the pre-built packages will only be used if 
that variant is NOT requested. See below for equivalent macOS versions.

Darwin version  macOS version
 1  10.0 Cheetah
 5  10.1 Puma (later minor versions, at any rate)
 6  10.2 Jaguar
 7  10.3 Panther
 8  10.4 Tiger
 9  10.5 Leopard
10  10.6 Snow Leopard
11  10.7 Lion
12  10.8 Mountain Lion
13  10.9 Mavericks
14  10.10 Yosemite
15  10.11 El Capitan
16  10.12 Sierra
17  10.13 High Sierra
18  10.14 Mojave
19  10.15 Catalina
20  11 Big Sur
21  12 Monterey



> On Nov 28, 2021, at 23:37, Kastus Shchuka  wrote:
> 
> Dear macports users,
> 
> Recently, more and more ports began to depend on rust and cargo.
> 
> Maybe rust is a wonderful language that will solve all problems of the world. 
> I just wonder, if it is so good, why it takes forever and a day (literally)  
> to compile? I've never seen anything taking that long to build. 
> 
> I've been using graphviz port for over 10 years, I guess. I had to delete it 
> today.
> 
> graphviz depends on gd2. gd2 depends on libheif. libheif depends on rav1e. 
> Now rav1e started depending on cargo-c, nasm, clang-13, cargo.
> An attempt to upgrade rav1e launched a build of cargo-c which I had to kill 
> as I did not have luxary to wait for tens of hours for it to finish.
> 
> I either have to keep outdated ports or stop using them and delete. 
> Unfortunately, the usable surface of macports started shrinking for me (or 
> should I call it "rusting"?). 
> 
> Another example is py-cryptography, which now requires rust to build. Until 
> binary package was made available, it took me over a day to upgrade 
> py-cryptography. 
> 
> I also now have a broken ImageMagic because its dependency chain pulls in 
> rust. And the list goes on and on.
> 
> I doubt people who rushed rust into macports are going to reconsider their 
> decisions. I am just sharing my experience with this "rusting"
> 
> Thank you 

Re: Does MacPorts depend on Spotlight?

[Richard L. Hamilton]

sh-3.2$ ls -ld@O /opt/local/var/macports
drwxr-xr-x@ 13 root  wheel  - 416 Apr 16  2021 /opt/local/var/macports
com.apple.FinderInfo 32 

sh-3.2$ lsmac /opt/local/var
[...]
I-   11 items  - macports/ 
[...]

Mine doesn't have the BSD (Windows compatibility) hidden flag, but it does have 
the Finder info "invisible" flag ( the "I" on the left in the 2nd output shown 
above) - two different things, no idea why both exist, probably compatibility).

I've never before seen mention of either flag blocking Spotlight in discussions 
of ways to block Spotlight from indexing certain files or folders/directories.


> On Nov 18, 2021, at 09:47, Eric Gallager  wrote:
> 
> On Thu, Nov 18, 2021 at 3:02 AM Ryan Schmidt  wrote:
>> 
>> MacPorts base doesn't do anything with Spotlight. It doesn't depend on it 
>> existing, nor does it tell Spotlight to index or not to index anything. 
>> MacPorts predates the existence of Spotlight.
>> 
>> As far as I know, ports don't depend on Spotlight having indexed the 
>> MacPorts prefix or the build directory. On the MacPorts buildbot machines, I 
>> exclude /opt/local and /Applications/MacPorts from the Spotlight index in 
>> order to reduce disk writes. As far as I know, this hasn't caused any build 
>> failures.
>> 
>> I do recall at least one port where we discovered that it was using `mdfind` 
>> (the command line utility for finding files using the Spotlight index) to 
>> find something it needed (Xcode, if I recall), and this failed for a user 
>> who had excluded either /Applications or maybe their whole disk from 
>> Spotlight or turned Spotlight off entirely, so I don't recommend doing that.
>> 
> 
> Didn't MacPorts start doing `chflags hidden` on
> /opt/local/var/macports at some point to stop Spotlight from indexing
> it? If it wasn't actually to stop Spotlight from indexing it, then why
> hide it? Also Fink makes Spotlight avoid its build directory by giving
> it a `.build` suffix; apparently a `.noindex` suffix ought to work,
> too; I've thought for a while that MacPorts should use one of these
> suffixes as well. Also Fink supplies a package that provides an
> importer that allows Spotlight to index its info files, which is
> something that I've wondered if it could be ported to MacPorts to
> create an `.mdimporter` for Portfiles, too:
> https://github.com/fink/fink-distributions/blob/4b95ece57eb9acdf68b7d4390914b59e16370bff/10.4/stable/main/finkinfo/devel/finkinfofile.info
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: Does MacPorts depend on Spotlight?

[Richard L. Hamilton]

Mos Applie-supplied command line tools and C programming interfaces are in man 
pages, the latter only if you have Xcode and/or command line developer tools 
installed (and those aren't on the default search path for the man command, so 
finding them might be non-obvious). Some command line programs are pretty much 
undocumented, you just have to google, typically finding where someone was 
complaining about them using too much CPU. :-)

Most Apple-supplied GUI tools have some built-in help. Apple programming 
interfaces intended to be public (not all are) that are Objective C or Swift 
have documentation on their developer website, along with a few other odds and 
ends probably.

The way man pages and the documentation on the Apple developer website are 
written is somewhat different. Someone familiar with one might not be so 
comfortable with the other, and vice versa. Man pages go all the way back to 
very early Unix systems which were used for typesetting, and could both 
recompile themselves and typeset their own documentation (pretty impressive on 
something far less powerful - if more general purpose - than an Apple Watch 
today is), including man pages but also some slightly more tutorial 
documentation. Documentation not part of man pages mostly (except for IBM 
mainframes and a few other systems that have been around for ages) has writing 
styles and structure that is typically much more recent. Man pages (and a lot 
of IBM mainframe documentation) are REFERENCE; they assume you already know 
more or less what does what, and just want to get the details right. They're 
not remotely meant to be an overview or tutorial, at least not unless you read 
a lot of them and try everything that doesn't look too dangerous. :-) Or read 
the OS source code, which is right (in terms of what actually  happens) even if 
the documentation isn't.


> On Nov 17, 2021, at 16:37, Dave Horsfall  wrote:
> 
> On Wed, 17 Nov 2021, Bill Cole wrote:
> 
>>> Where are all these obscure commands documented?
>> 
>> /usr/share/man/man1/ and /usr/share/man/man8/ mostly...
> 
> Perhaps I should've expressed it better :-)
> 
> I've found all sorts of obscure commands (such as "security" and the 
> aforementioned "mdutil") mentioned on this list; now, how am I supposed to 
> know that they existed in the first place?  I cannot find any sign of an 
> admin guide, and this 2nd-hand MacPro did not come with media.
> 
> It seems that I have to look at all the manfiles and wonder what they do...
> 
>> FWIW, 'apropos spotlight' will tell you that mdutil and mddiagnose exist.
> 
> Sure, but my query was more of a general nature.
> 
> -- Dave
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: Does MacPorts depend on Spotlight?

[Richard L. Hamilton]

> On Nov 17, 2021, at 14:16, André-John Mas  wrote:
> 
> When looking at "System Preferences -> Spotlight -> Privacy", you can 
> configure exclusions by folder.
> 
> I had a look at the mdutil command and no reference to folders or paths is 
> mentioned, when looking from macOS 12.0.1:
> 
> Usage: mdutil -pEsa -i (on|off) -d volume ...
>mdutil -t {volume-path | deviceid} fileid
>   Utility to manage Spotlight indexes.
>   -i (on|off)Turn indexing on or off.
>   -d Disable Spotlight activity for volume (re-enable using 
> -i on).
>   -E Erase and rebuild index.
>   -s Print indexing status.
>   -a Apply command to all stores on all volumes.
>   -t Resolve files from file id with an optional volume path 
> or device id.
>   -p Publish metadata.
>   -V vol Apply command to all stores on the specified volume.
>   -v Display verbose information.
>   -r plugins Ask the server to reimport files for UTIs claimed by the 
> listed plugin.
>   -L volume-path List the directory contents of the Spotlight index on 
> the specified volume.
>   -P volume-path Dump the VolumeConfig.plist for the specified volume.
>   -X volume-path Remove the Spotlight index directory on the specified 
> volume.  Does not disable indexing.
>  Spotlight will reevaluate volume when it is unmounted 
> and remounted, the
>  machine is rebooted, or an explicit index command such 
> as 'mdutil -i' or 'mdutil -E' is
>  run for the volume.
> NOTE: Run as owner for network homes, otherwise run as root.
> 
> I am starting to wonder if there is another command we should be using, in 
> place of mdutil?

As I implied before, I don't think there's an md* command or even a public API 
to add or edit the folders to exclude. Rather, I suspect that the Spotlight 
preference pane has some private interface to do the job.

I could probably figure out how to do that using the "defaults" command and 
tell you, but I won't, because the risk of corrupting that file and possibly 
breaking Spotlight for that volume is one I won't encourage. Figure it out 
yourself if you're willing to risk shooting yourself in the foot. Looking a bit 
at the executable for the preference pane, I don't quite see what it does (it 
doesn't seem to directly edit the .Spotlight-V100/VolumeConfiguration.plist 
file for the volume (I think that tree exists per-volume, not just one for the 
whole system), but I haven't looked closely to determine more), but it seems 
that it may at least take some precautions you might not - there seems to be 
some check for paths that might break (presumably Apple-supplied - they 
couldn't know what other apps do) apps that depend on Spotlight access to 
certain directories.

So I agree that MacPorts shouldn't exclude its noisy (with respect to Spotlight 
updates) directory automatically. If it's a performance problem, it's easily 
enough done through the preference pane.

Re: Does MacPorts depend on Spotlight?

[Richard L. Hamilton]

I also haven't found an intended command line way or program API to add a 
directory to exclude from Spotlight. (they are buried in a plist file in the 
Spotlight data directory for the particular mount point, and one could use 
command line tools to add it there, but I would NOT recommend risking it)

But in System Preferences ->Spotlight->Privacy tab, the usual command-shift-G 
type the path works just fine to set a directory (not needing to be a volume 
mount point) to exclude. That's probably needed because /opt/local/var/macports 
has the Finder invisible flag set.

> On Nov 17, 2021, at 13:31, Peter Hancock  wrote:
> 
> On 17/11/2021 15:46, Chris Jones wrote:
>> Some users might find it useful, and the exact volume to exclude
>> depends on the details of the users installation, which would be
>> difficult to automate. So I think its fine to just leave it to be
>> done by hand by those that wish to.
>> On 17/11/2021 3:09 pm, André-John Mas wrote:
>>> Just wondering whether it would make sense for MacPorts to auto
>>> exclude that folder? Does spotlight even provide an API or command
>>> that would allow MacPorts to do that?>>
> 
> André-John Mas mentions folders (directories?), while Chris Jones mentions 
> volumes
> (mounted filesystems?).
> 
> On Catalina, for me the command "sudo mdutil -i off /opt/local/var/macports "
> evokes:
> [
> Password:
> /System/Volumes/Data/opt/local/var/macports:
> Error: invalid operation.
>   Error: unknown indexing state.
> ]
> 
> Trying to drag that directory into the appropriate System Preferences 
> "privacy" pane,
> accomplishes nothing. It doesn't appear on the list.
> 
> My man page for mdutil seems to speak only about volumes. A bit of googling 
> suggests
> that though there *may* have been a time when you could exclude various 
> directories
> from spotlight indexing, by one trick or another, those days are gone.
> 
> Am I wrong?
> 
> I hope so. I'm getting pretty dyspeptic about how much of my computer seems 
> to be
> taken over by Spotlight and it's various underlings/minions.
> 
> (Eg, It/they seem(s) to spend a large chunk of resources on creating 
> tens/hundreds of thousands
> of empty directories deep under /private/var/folders, to no apparent purpose.)
> 
> 
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: Does MacPorts depend on Spotlight?

[Richard L. Hamilton]

Good, thanks. Perhaps I wouldn't exclude the whole /opt/local (or whatever 
install prefix) unless performance is a major issue, but 
/opt/local/var/macports, which is less likely to be interesting in terms of 
commands or configuration files or documentation, and both large (mine is 24GiB 
when the entire /opt/local is only 35GiB - and I frequently remove most 
inactive ports and run a port clean installed) and active in terms of changes.

> On Nov 16, 2021, at 16:06, Chris Jones  wrote:
> 
> 
> I am not aware of any use macports itself makes of spotlight, so for sure if 
> you don’t plan on using it yourself to search the install prefix, you can 
> disable it.
> 
>> On 16 Nov 2021, at 6:26 am, Richard L. Hamilton  wrote:
>> 
>> Seems it'd thrash Spotlight a lot less during "port selfupdate" or "port 
>> upgrade outdated" to exclude /opt/local, as long as that wouldn't break 
>> anything (obviously one couldn't then use Spotlight to search /opt/local, 
>> but that's ok with me).
>> 
>> 

-- 
eMail:  mailto:rlha...@smart.net

Does MacPorts depend on Spotlight?

[Richard L. Hamilton]

Seems it'd thrash Spotlight a lot less during "port selfupdate" or "port 
upgrade outdated" to exclude /opt/local, as long as that wouldn't break 
anything (obviously one couldn't then use Spotlight to search /opt/local, but 
that's ok with me).

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

mpstats uses (by default the OS version of) libcurl (which you don't want to 
replace like that!) and not the executable, which is why what you tried didn't 
work (didn't work for me either when I'd tried earlier).

As things stand, one would have to get the MacPorts source (not a port!) and 
build it with an option to use its own version of curl / libcurl. Or so someone 
explained in response to a comment I'd made on a ticket about mpstats.

> On Nov 5, 2021, at 20:58, raf  wrote:
> 
> On Fri, Nov 05, 2021 at 09:30:28AM -0500, Ryan Schmidt 
>  wrote:
> 
>> On Oct 31, 2021, at 04:37, raf wrote:
>> 
>>> On 10.14:
>>> 
 /opt/local/libexec/mpstats submit
>>> Submitting data to https://ports.macports.org/statistics/submit/ ...
>>> Error: Peer certificate cannot be authenticated with given CA certificates
>>> while executing
>>> "curl post "submission\[data\]=$json" $stats_url"
>> 
>> We need to make a server configuration change. See
>> 
>> https://trac.macports.org/ticket/63809
> 
> Thanks.
> 
> Unfortunately, mpstats submit still doesn't work on 10.6.8,
> even with /usr/bin/curl replaced with a symlink to
> /opt/local/bin/curl. I don't understand that.
> /usr/bin/curl https://ports.macports.org works there with
> the symlink in place.
> 
> cheers,
> raf
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

I tried that too, and it didn't work for me either. Turns out from a comment on 
that ticket I mentioned previously that mpstats and other MacPorts commands 
(like "port"?) don't use /usr/bin/curl, they have a tcl binding to (by default, 
the system version of) libcurl. So replacing the executable doesn't help. I 
gather one can replace MacPorts (not the ports, but the base installation) with 
a version compiled from source with an option to use its own curl (or actually 
libcurl) rather than the system one Looks like a bit of a nuisance to do; 
apparently there's been long unresolved discussion about whether or not to 
change the default installation to do that, but while I see the upside to the 
change (more stuff works on older systems, and their stats  don't go 
unreported), I haven't seen the downside arguments.

> On Nov 3, 2021, at 00:39, raf  wrote:
> Thanks! That worked on 10.14. I couldn't find the equivalent cert.pem
> file for /usr/bin/curl on 10.6.8 (not that the same thing would have
> worked there anyway), so I did this instead:
> 
>  cd /usr/bin
>  mv curl curl.orig
>  ln -s /opt/local/bin/curl curl
> 
> After that, "/usr/bin/curl https://ports.macports.org; worked
> but "/opt/local/libexec/mpstats submit" still fails
> with the same error.
> 
> cheers,
> raf
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

> On Nov 1, 2021, at 03:12, raf  wrote:
> 
> On Sat, Oct 30, 2021 at 05:49:11AM -0700, Al Varnell via macports-users 
>  wrote:
> 
>> I see that I already have the latest ISRG Root X1 certificate in the
>> System Roots keychain, so not sure why I would need to add it to my
>> System keychain.
> 
> It doesn't sound sensible, does it? I followed those instructions,
> then added it to System Roots because it hadn't changed anything,
> only to discover (on 10.6) that only TLSv1.0 was supported by the
> system-supplied software so things wouldn't work anyway.
> 
> I still don't understand why /usr/bin/curl isn't working for me on
> 10.14 but Safari is.

/usr/bin/curl (also?) uses /etc/ssl/cert.pem file. Copy that file to 
/etc/ssl/cert.pem.orig as a backup and look around line 1130 for the following:

### Digital Signature Trust Co.

=== /O=Digital Signature Trust Co./CN=DST Root CA X3
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
Signature Algorithm: sha1WithRSAEncryption
Validity
Not Before: Sep 30 21:12:19 2000 GMT
Not After : Sep 30 14:01:15 2021 GMT
Subject: O=Digital Signature Trust Co., CN=DST Root CA X3
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:TRUE 
X509v3 Key Usage: critical
Certificate Sign, CRL Sign 
X509v3 Subject Key Identifier:
C4:A7:B1:A4:7B:2C:71:FA:DB:E1:4B:90:75:FF:C4:15:60:85:89:10
SHA1 Fingerprint=DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13
SHA256 
Fingerprint=06:87:26:03:31:A7:24:03:D9:09:F1:05:E6:9B:CF:0D:32:E1:BD:24:93:FF:C6:D9:20:6D:11:BC:D6:77:07:39
-BEGIN CERTIFICATE-


Remove from there (if it is line 1130) to the matching
-END CERTIFICATE-
line in /etc/ssl/cert.pem (around 1171) and that gets rid of the expired X3 
cert that doesn't really need to be in the certificate chain. After that,
/opt/local/libexec/mpstats submit
works for me on 10.14. Still doesn't help with what's presumably the TLS 
problem on older versions (10.6.8 being the only older version I have 
available, so I don't know just what version is the cutoff for that problem).

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

https://trac.macports.org/ticket/61333 <https://trac.macports.org/ticket/61333> 
is an old ticket about mpstats not reporting on Tiger and Leopard. The problem 
also exists on Snow Leopard (not just certificates there) and as recently as 
Mojave (certificates). The general solution IMO is that mpstats should depend 
on the curl port and always use that version of curl and not the OS version. I 
added a comment to that effect. I don't know how to change the keywords to add 
later OS versions up through Mojave, though.

> On Oct 31, 2021, at 07:59, Richard L. Hamilton  wrote:
> 
> I think you're onto something here. (color highlighting added, not in the 
> original output)
> 
> sh-3.2$ # 10.14
> sh-3.2$ /usr/bin/curl -sS https://ports.macports.org 
> <https://ports.macports.org/> >/dev/null
> curl: (60) SSL certificate problem: certificate has expired
> # lines of advice in error message skipped here
> sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org 
> <https://ports.macports.org/> >/dev/null
> sh-3.2$ echo $?
> 0
> 
> (the expired above isn't surprising since I haven't updated the root 
> certificates on there)
> 
> but
> 
> sh-3.2$ # 10.6
> sh-3.2$ /usr/bin/curl -sS https://ports.macports.org/ 
> <https://ports.macports.org/> >/dev/null
> curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert 
> protocol version
> sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org/ 
> <https://ports.macports.org/> >/dev/null
> sh-3.2$ echo $?
> 0
> 
> On the 10.6, I had updated the root certificates...but the error is 
> different; evidently there have been changes to the protocol and/or crypto 
> used that merely updating the certificates does not fix. The MacPorts version 
> of curl still works fine. Note that  pointing Safari to that same URL 
> (https://ports.macports.org/ <https://ports.macports.org/>) also fails with 
> unable to establish secure connection. So on older systems, EVEN WITH 
> CERTIFICATES UPDATED, browsing with a non-updated browser and/or one that 
> uses system libcrypto will fail for various sites, as will various 
> non-browser software that tries to establish TLS connections using system 
> libcrypto.
> 
> So if mpstats is failing on curl, it's not using the MacPorts version of 
> curl. Which certainly would be distorting the stats against the poor 
> suffering older OS version users, even if, knowing they're poor and 
> suffering, they volunteer to provide stats.
> 
> IMO, it should check if ${prefix}/bin/curl is present and use it if it is, 
> and only use the default if that isn't present - which in practice probably 
> would never happen, because so many ports ultimately depend on the curl port. 
> Interestingly it did NOT matter if PATH began with /opt/local/bin when 
> mpstats was run, it still found the OS version rather than the MacPorts 
> version.
> 
>> On Oct 31, 2021, at 05:37, raf mailto:macpo...@raf.org>> 
>> wrote:
>> 
>> 
>> Actually, something looks wierd with macports statistics.
>> 
>> On 10.14:
>> 
>>> /opt/local/libexec/mpstats submit
>>  Submitting data to https://ports.macports.org/statistics/submit/ 
>> <https://ports.macports.org/statistics/submit/> ...
>>  Error: Peer certificate cannot be authenticated with given CA certificates
>>  while executing
>>  "curl post "submission\[data\]=$json" $stats_url"
>> 
>> On 10.6:
>> 
>>> /opt/local/libexec/mpstats submit
>>  Submitting data to https://ports.macports.org/statistics/submit/ 
>> <https://ports.macports.org/statistics/submit/> ...
>>  Error: SSL connect error
>>  while executing
>>  "curl post "submission\[data\]=$json" $stats_url"
>> 
>> It has a LetsEncrypt certificate but this should work. It should be macport's
>> curl that has its own CA bundle.
>> 
>> The certificate chain does still contain "DST Root CA X3". I thought that
>> was getting removed.
>> 
>> Anyway, it looks like I didn't manage to fix my system root certificates
>> after all, even though "ISRG Root X1" is installed (and "DST Root XA 3" is
>> manually trusted just to be extra sure). :-)
>> 
>> /usr/bin/curl is still failing, and for some reason, mpstats must be using
>> /usr/bin/curl instead of /opt/local/bin/curl. That doesn't sound possible, 
>> but
>> that's what it looks like.
>> 
>> According to check_for_app in 
>> /opt/local/libexec/macports/lib/macports1.0/diagnose.tcl,
>> it looks like the curl that's used is the system one in /usr/bin.
>> 
>>

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

Years ago, creating a (then OS X, now macOS) VM under free VirtualBox was a 
horrid pain (which is why I'm running the relatively expensive but nicer 
Parallels for that and VMs other than Solaris).

But apparently now it's relatively easy. You do need plenty of extra disk space 
and I'd say 8GB more ram than you'd otherwise need. See 
https://www.soupbowl.io/2020/04/macos-in-virtualbox/
(I haven't tried it, but it looks believable)


> On Oct 31, 2021, at 06:46, Henning Hraban Ramm  wrote:
> 
> I’m working on a 2013 Mac mini and can’t upgrade further than 10.14 (don’t 
> want to loose my 32 bit software, and I seem too stupid for VMs).

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

I think you're onto something here. (color highlighting added, not in the 
original output)

sh-3.2$ # 10.14
sh-3.2$ /usr/bin/curl -sS https://ports.macports.org >/dev/null
curl: (60) SSL certificate problem: certificate has expired
# lines of advice in error message skipped here
sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org >/dev/null
sh-3.2$ echo $?
0

(the expired above isn't surprising since I haven't updated the root 
certificates on there)

but

sh-3.2$ # 10.6
sh-3.2$ /usr/bin/curl -sS https://ports.macports.org/ >/dev/null
curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert 
protocol version
sh-3.2$ /opt/local/bin/curl -sS https://ports.macports.org/ >/dev/null
sh-3.2$ echo $?
0

On the 10.6, I had updated the root certificates...but the error is different; 
evidently there have been changes to the protocol and/or crypto used that 
merely updating the certificates does not fix. The MacPorts version of curl 
still works fine. Note that  pointing Safari to that same URL 
(https://ports.macports.org/) also fails with unable to establish secure 
connection. So on older systems, EVEN WITH CERTIFICATES UPDATED, browsing with 
a non-updated browser and/or one that uses system libcrypto will fail for 
various sites, as will various non-browser software that tries to establish TLS 
connections using system libcrypto.

So if mpstats is failing on curl, it's not using the MacPorts version of curl. 
Which certainly would be distorting the stats against the poor suffering older 
OS version users, even if, knowing they're poor and suffering, they volunteer 
to provide stats.

IMO, it should check if ${prefix}/bin/curl is present and use it if it is, and 
only use the default if that isn't present - which in practice probably would 
never happen, because so many ports ultimately depend on the curl port. 
Interestingly it did NOT matter if PATH began with /opt/local/bin when mpstats 
was run, it still found the OS version rather than the MacPorts version.

> On Oct 31, 2021, at 05:37, raf  wrote:
> 
> 
> Actually, something looks wierd with macports statistics.
> 
> On 10.14:
> 
>> /opt/local/libexec/mpstats submit
>  Submitting data to https://ports.macports.org/statistics/submit/ ...
>  Error: Peer certificate cannot be authenticated with given CA certificates
>  while executing
>  "curl post "submission\[data\]=$json" $stats_url"
> 
> On 10.6:
> 
>> /opt/local/libexec/mpstats submit
>  Submitting data to https://ports.macports.org/statistics/submit/ ...
>  Error: SSL connect error
>  while executing
>  "curl post "submission\[data\]=$json" $stats_url"
> 
> It has a LetsEncrypt certificate but this should work. It should be macport's
> curl that has its own CA bundle.
> 
> The certificate chain does still contain "DST Root CA X3". I thought that
> was getting removed.
> 
> Anyway, it looks like I didn't manage to fix my system root certificates
> after all, even though "ISRG Root X1" is installed (and "DST Root XA 3" is
> manually trusted just to be extra sure). :-)
> 
> /usr/bin/curl is still failing, and for some reason, mpstats must be using
> /usr/bin/curl instead of /opt/local/bin/curl. That doesn't sound possible, but
> that's what it looks like.
> 
> According to check_for_app in 
> /opt/local/libexec/macports/lib/macports1.0/diagnose.tcl,
> it looks like the curl that's used is the system one in /usr/bin.
> 
> I think that means that macports does require the system root certificates
> to be functional (for some things at least). Is anyone else on old systems
> able to run "/opt/local/libexec/mpstats submit"? I read somewhere that errors
> are silently ignored during automatic submission.
> 
> Could this be why https://ports.macports.org/statistics/ shows almost nothing
> for 10.{14,13,8,7,6,5,4}? Or are those numbers accurate?
> 
> cheers,
> raf
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

Neither does Osborne Computer Corporation. :-) But that's a hobby, and doesn't 
have connectivity issues anyway. But I don't run the browser on my Sun 
workstation, either (an ancient version of Firefox, I think; I may still have 
Mosaic on there, but that's so old it's just plain useless).

FWIW, I find a refurbished late 2014 Mac Mini (oldest low-end Mac that can run 
Monterey) at OWC for as little as $189 (doubtless a low end config, but likely 
competitive with something even older). That's not even the lowest possible 
price, just the low end of what I saw in 10 seconds looking at search results, 
from a reputable seller. More looking could beat that. Heck, someone here may 
have something non-ancient (at least able to run Catalina, which still gets 
security updates) they'd be willing to part with for the cost of shipping. 
Alas, not me; I'm the graveyard of old computers, as that Osborne (and an even 
older Exidy Sorcerer) might suggest.

Is there a modern GUI browser in MacPorts, that uses only libs supplied by 
MacPorts (aside from libSystem)? If so, using that might be kinda sorta safer 
than using Safari on a system with no current security updates.

> On Oct 29, 2021, at 12:45, Richard Bonomo TDS personal  wrote:
> 
> 
> Well, some of us are reasonably competent in managing risk, but cannot afford 
> to be buying new computers.
> So the Apples I have, or are on loan to me, have to be kept going.
> 
> On a more pathologic level, I am also in possession (extended load) of a µVAX 
> workstation that I should try
> to get working again.  There is no such thing as a support contract for that, 
> and DEC does not exist any more.
> 
> Rich
> 
> ----- Original Message -
> From: "Richard L. Hamilton" 
> To: "macports-users Users" 
> Sent: Friday, October 29, 2021 11:25:56 AM
> Subject: Re: provide latest OS root certificates via port?
> 
> 
> 
>> On Oct 29, 2021, at 12:02, Michael  wrote:
>> 
>> 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.
> 
> The ancient (and inadequately audited and reviewed, even if not ancient) 
> software on ATMs and voting machines should be a scandal. Although they are 
> (supposedly) more physically controlled than user desktops/laptops are, and 
> are at least INTENDED to be limited to specific kiosk-like functions and 
> nothing else, so they're FAR less exposed (software-wise) than a browser 
> accessing potentially anything, including once-legit sites that had been 
> hacked to become nasty.  The risks are (IMO) NOT THE SAME.
> 
>> 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?
> 
> A heck of a lot had to be fixed for Y2K, and some things that couldn't be 
> fixed were either replaced or tossed (including a few that were tossed simply 
> because nobody would take responsibility to affirm that they didn't use 
> dates, even though it was obvious). Been there, done that. It was only a big 
> yawn-fest due to a LOT of hard work. Same thing will happen again in 2038 for 
> any 32-bit Unix/Linux code, btw. That won't be modern desktops (just about 
> all of which are already 64-bit, some now 64-bit only), but a heck of a lot 
> of embedded devices may still be running that old code then. Fortunately I'm 
> retired, so assuming I'm still around, I won't have to deal with THAT me

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

> On Oct 29, 2021, at 12:02, Michael  wrote:
> 
> 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.

The ancient (and inadequately audited and reviewed, even if not ancient) 
software on ATMs and voting machines should be a scandal. Although they are 
(supposedly) more physically controlled than user desktops/laptops are, and are 
at least INTENDED to be limited to specific kiosk-like functions and nothing 
else, so they're FAR less exposed (software-wise) than a browser accessing 
potentially anything, including once-legit sites that had been hacked to become 
nasty.  The risks are (IMO) NOT THE SAME.

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

A heck of a lot had to be fixed for Y2K, and some things that couldn't be fixed 
were either replaced or tossed (including a few that were tossed simply because 
nobody would take responsibility to affirm that they didn't use dates, even 
though it was obvious). Been there, done that. It was only a big yawn-fest due 
to a LOT of hard work. Same thing will happen again in 2038 for any 32-bit 
Unix/Linux code, btw. That won't be modern desktops (just about all of which 
are already 64-bit, some now 64-bit only), but a heck of a lot of embedded 
devices may still be running that old code then. Fortunately I'm retired, so 
assuming I'm still around, I won't have to deal with THAT mess.

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

Ok, sometimes. In a retro computing museum. Or in a nonprofit with no budget. 
But for anything serious, one REALLY should be aware of the risks, even if that 
means going back to pen, paper, and snail mail rather than taking the risks. Or 
else realizing that EVERYTHING they do where the information or transaction has 
any value at all, is at greater risk of being corrupted or exploited by 
hostiles if they're doing it on that old system, at least if that system has 
Internet access.

But basically EVERY computer, even if the physical box could last longer, has 
support issues past 5 years old, CERTAINLY if one doesn't have a paid support 
contract. I have a box that's industrial enough that it's 20+ years old and has 
only had a drive or two (mirrored, so never any data loss) replaced, but I 
can't (ok, won't) afford a support contract for it (there probably is still 
support for an older OS version that could still run on it, those things were 
built like tanks!), so I know I'm taking my chances. In other words, no system 
seller is going to be on the hook to support an old system forever as part of 
the purchase price; if they'll provide extended support at all, you'd better 
expect to pay extra for that, every year. EVERYTHING costs, 'cause everybody 
has to make a living, including the rich people and the little people at the 
rich people's companies. Magic no problems forever does NOT exist.

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

I have VMs of a couple of old macOS / OS X versions, because I want continued 
access to the features that have been removed in more recent versions (32-bit 
user land support in Mojave, ability to run PowerPC apps and executables in 
Snow Leopard).

But the old machine that ran Snow Leopard is pretty much dead (why I built a 
Snow Leopard VM with all its apps copied over to replace it before it died 
completely). So everything runs on newer systems, but I can still run the old 
OS versions as VMs if I need them.

One might of course need more $$ to obtain a newer system (although one can 
probably scrounge a deal on a newer enough used one, if one is careful).

So I'm not sure what the limitation would be to ONLY using an old system - 
although if businesses or bureaucrats are involved, limitations may not be 
sensible.

> On Oct 29, 2021, at 11:17, 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 of sites because a crucial root certificate has 
>>> expired.
>>> 
>>> Answer 1 to 
>>> https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
>>>  
>>> provides an easy

Re: provide latest OS root certificates via port?

[Richard L. Hamilton]

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.

> 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 of 
> sites because a crucial root certificate has expired.
> 
> Answer 1 to 
> https://apple.stackexchange.com/questions/422332/how-do-i-update-my-root-certificates-on-an-older-version-of-mac-os-e-g-el-capi
>  provides an easy solution, but you need access to an up-to-date OS install.
> 
> These are not proprietary to Apple so I presume it should be possible to 
> provide the suggested `rootcerts.pem` file via a port - possibly even install 
> it in the post-activate. I had a look but couldn't find if such a port 
> already exists. I think it'd help for lots of people... I'd propose a draft 
> but I'm running 10.9 ... so thanks to anyone picking this up!
> 
> R.
> 

Re: Is there a binary editor for MacPorts?

[Richard L. Hamilton]

HexFiend (installs /Applications/MacPorts/Hex Fiend.app) is a true binary 
editor; it shows a split view, hex on the left, characters (ASCII with anything 
else replaced with periods or spaces, I guess) on the right; you can edit 
either side. Unlike some binary editors, it can handle insertions or deletions, 
not just changes in-place, although you can use Edit->Mode->Overwrite to avoid 
accidents insertions if you really want overwrite. It can apparently handle 
really huge files. It has a GUI interface, and it's not at all like vi/vim.

Whether that's REALLY what you want, given both its apparent strengths and 
limitations (i.e. what character sets it can handle - I don't think it can 
usefully display various 8-bit character sets or UTF-16 or UCS-32) is your call.

port info HexFiend

for more info. Unfortunately it doesn't seem to include builtin help, and if 
there's any documentation beyond the brief description (and a bit more on 
templates on their web site, google for Hex Fiend), I haven't found it.


> On Sep 22, 2021, at 17:26, Dave Horsfall  wrote:
> 
> I can see heaps of 3rd-party stuff out there, but is there an "official" one?
> 
> I have a file with some binary stuff in it (8-bit accents, perhaps?) and "vi" 
> just spits the dummy at that point and I want to search down further.
> 
> Thanks.
> 
> -- Dave
> 

-- 
eMail:  mailto:rlha...@smart.net

Re: socks proxy server for macOS?

[Richard L. Hamilton]

Thanks - that's a bit more brute force than I had in mind, but it should do the 
job, at least for a week or two until things get more normal, although in the 
long run, I'd still rather have a socks server other than ssh.

I use screen rather than tmux myself, but that's because I already had it on 
everything (comes with macOS at least back to the oldest I have, and likewise 
all or just about all of the Solaris and Linux I have, so under normal 
circumstances, when I run a Terminal window with 21 tabs worth of different 
systems or VMs being updated all at once, each is happening in screen in case 
something hiccups, so that the sessions can be resumed).

> On Aug 28, 2021, at 12:44, Eric Borisch  wrote:
> 
> If ssh -D is dying, it's likely due to a dropped connection; you could always 
> (assuming you have public keys set for passwordless connection) make a script 
> like:
> 
> #!/bin/sh
> while true; do
>ssh -D proxy_host
>sleep 5
> done
> 
> Every time SSH exits, this will kick it off again, with a sleep in there so 
> if there's no connection at all you're not trying to spawn SSH hundreds of 
> times a second.
> 
> Run it inside a tmux that you can detach from for ease of management; you can 
> always get back to it, but you can also detach and let it happily run in the 
> background. I'd also use -o serveraliveinterval=30 to make sure the 
> connection is kept alive.
> 
> Good luck, 
>   - Eric
> 
> On Sat, Aug 28, 2021 at 10:46 AM Richard L. Hamilton  <mailto:rlha...@smart.net>> wrote:
> Is there a robust socks5 proxy server for macOS? And no, I do not mean the -D 
> option of ssh; although it works, it dies daily, more or less.
> 
> For FreeBSD, Linux, and Solaris, it seems that ss5 is often mentioned, And if 
> something that may not need much OS specific code builds on FreeBSD, I'd like 
> to think it wouldn't be too hard to build on macOS; but I haven't tried yet, 
> and haven't found an example of someone else trying.
> 
> Has anyone built ss5 for macOS? Or is there a port of some socks5 server that 
> could run, preferably in background (LaunchDaemon or whatever) on macOS?
> 
> Sometimes, my main connectivity is cr@p, and my Macs  aren't close enough 
> together to use the phone's WiFi (no stronger than it has to be) all as a 
> hotspot; and macOS client side socks5 proxy support (to the laptop with the 
> iPhone plugged into it) is decent enough to use the App Store and some other 
> things to keep them somewhat up to date. So until the weather cools down 
> some, this would be really helpful. :-)
> 

-- 
eMail:  mailto:rlha...@smart.net