Re: Why would Kreversi want a spell checker?

[Ian Wadham]

> On 20 Nov 2022, at 9:51 am, Sriranga Veeraraghavan  
> wrote:
> 
> Hi Dave,
> 
> I think that you are correct - aspell is a dependency of KDE itself.  
> 
> Looking at the port info for kreversi, it looks like kreversi depends on 
> kdelibs4, which in turn depends on aspell.

That would definitely be the case. 

I used to be a KDE4 Games developer, using Apple MacBook, with MacPorts to get 
the libraries. They are huge and have a huge chain of dependencies for every 
KDE app, such as an entire desktop text-indexing system and relational database 
(which never worked too well, FWICG). 

The KDE Core Developers’ solution was to re-design the entire library system as 
small modules with fewer dependencies. That collection is called KF5 
Frameworks. And the desktop indexing (for Linux systems) is now done by KDE’s 
Baloo application. On Apple, of course, we have Spotlight for that.

A few of us tried, but we never succeeded in porting KF5 Frameworks and Qt5 to 
MacPorts. So my career as a KDE developer ended there. Also, the KDE4 apps in 
MacPorts are gradually bit-rotting away with every new Apple release of an O/S.

The KDE games still work for me on Catalina and Intel hardware (MacBook Pro 13 
inch 2017), but I can no longer get KMyMoney4 to work properly. Also I have 
struck a brick wall on my new MacBook Pro 13 inch with Monterrey and the new 
Apple CPU hardware. I cannot get Qt4 and kdelibs4 to build on that combo.

So be alert but not alarmed, Dave.

Cheers, Ian W.

> 
> -ranga
> 
>> On Nov 19, 2022, at 12:09, Dave Horsfall  wrote:
>> 
>> MacBook Pro 13", mid 2010; High Sierra 10.13.6.
>> 
>> Kreversi is an implementation of the board game "reversi", but it fails 
>> with:
>> 
>># port install kreversi
>>--->  Computing dependencies for kreversi
>>Error: Can't install aspell because conflicting ports are active: ispell
>>Error: Follow https://guide.macports.org/#project.tickets if you believe 
>> there is a bug.
>>Error: Processing of port kreversi failed
>> 
>> No error log that I can see, but why on earth would a spell checker be 
>> required for a simple board game?  Is it because of KDE (ugh!) itself?
>> 
>> -- Dave
> 

Re: Catelina xcode

[Ian Wadham]

Hi James,

> On 12 Oct 2022, at 2:46 pm, James Linder  wrote:
> 
> Hi
> 
> slightly OT for macports but definitly onT. :)
> 
> My wife’s machine is Catelina (and Ends at Big Sur). It has, and I/She uses 
> lots of ports and IIRC we have used Qt before, but when I try to build 
> something I get the XCode license dialog. No worries, accept. "Something is 
> wrong see the log”
> The something wrong turn out to be Certificate Expired.
> After spelunking I got an Xcode for catelina. Install. "Something is wrong 
> see the log” Again Certificate Expired.
> 
> OK I’m starting to fumble. Setting her date back for a build is like a lead 
> balloon.
> A VM with no internet sccess ?
> 
> Any body able to guide me please?
> 
> James

I also have Catalina (version 10.15.7). My Xcode version is 12.4 and I have no 
Certificate Expired problems.

I have not used Xcode for a month or two on this machine, so am not sure how 
well my version is working, but it was certainly OK with MacPorts back then.

Maybe you need to change your version of Xcode(?). 

Caveat: Version 12 of Xcode is huge in download time, install time and disk 
space occupied, so tread carefully.

Cheers, Ian W.

Re: MacPorts downloaded package with wrong architecture on arm64 machine

[Ian Wadham]

Hi Ryan,

Thank you very much for your reply.

> On 9 Sep 2022, at 1:44 pm, Ryan Schmidt  wrote:
> 
> On Aug 30, 2022, at 20:57, Ian Wadham wrote:
>> 
>> I recently purchased a new MacBook Pro with Monterey O/S and installed 
>> MacPorts on it from scratch.
>> 
>> I installed the qt4-mac port successfully, but kdelibs4 refused to install 
>> because the qt4-mac port did
>> not support arm64 architecture and i am on an Apple Silicon arm64 machine.
>> 
>> The problem arose because the installation process for qt4-mac included the 
>> steps:
>> 
>> —>  Attempting to fetch qt4-mac-4.8.7_13.darwin_21.x86_64.tbz from 
>> https://packages.macports.org/qt4-mac
>> —>  Attempting to fetch qt4-mac-4.8.7_13.darwin_21.x86_64.tbz.rmd160 from 
>> https://packages.macports.org/qt4-mac
>> 
>> The second step succeeded, i.e. MacPorts itself downloaded an inappropriate 
>> package for an Apple
>> Silicon machine. I noticed that some (maybe not all) of qt4-mac’s 
>> dependencies were compiled or
>> downloaded as arm64 code and, curiously, some of Qt4’s utility apps work on 
>> my machine, perhaps
>> due to the Rosetta emulator stepping in and taking over.
>> 
>> The kdelibs4 install failed in the “Computing dependencies…” step, saying 
>> “Error: Cannot install kdelibs4 for
>> the arch arm64 because its dependency qt4-mac only supports the archs ‘ppc 
>> ppc64 i386 x86_64’”
>> 
>> Is this a bug or is it the end of the line for kdelibs4 on arch64? Can 
>> kdelibs4 really build as arch64? And what
>> about its (enormous) list of other dependencies? Do they all build for 
>> arch64?
>> 
>> If there is a bug here, I think it is that MacPorts can download a package 
>> for an inappropriate architecture.
> 
> MacPorts correctly installed qt4-mac for x86_64 on your machine because 
> qt4-mac does not support arm64. The x86_64 qt4-mac will work on your arm64 
> Mac via Rosetta 2 dynamic translation.
> 
> kdelibs4, and all other ports that use qt4-mac, need to be declared to be 
> arm64-incompatible, due to qt4-mac's arm64 incompatibility.
> 
> See https://trac.macports.org/ticket/65765
> 

Even if someone can get kdelibs4 and qt4-mac to play nicely together on arm64 
Apple Silicon architecture, using Rosetta, I don’t hold out much hope for 
kdelibs4’s other dependencies, which are numerous and complex and quite huge. 

They are one reason why the KDE team switched to a radically different library 
organisation called Frameworks or KF5, based on Qt5.

I think most of the KDE apps have been ported and are up-to-date on KF5 and Qt5 
and installable in Linux and Windows. But availability on Mac appears to be a 
grey area (pace Homebrew).

The KDE4 versions of the apps still work quite well on MacPorts on an x86_64 
machine, although KMyMoney4 no longer works for me on my older MacBook (2017 
vintage).

Cheers,
Ian Wadham.

MacPorts downloaded package with wrong architecture on arm64 machine

[Ian Wadham]

I recently purchased a new MacBook Pro with Monterey O/S and installed MacPorts 
on it from scratch.

I installed the qt4-mac port successfully, but kdelibs4 refused to install 
because the qt4-mac port did
not support arm64 architecture and i am on an Apple Silicon arm64 machine.

The problem arose because the installation process for qt4-mac included the 
steps:

—>  Attempting to fetch qt4-mac-4.8.7_13.darwin_21.x86_64.tbz from 
https://packages.macports.org/qt4-mac
—>  Attempting to fetch qt4-mac-4.8.7_13.darwin_21.x86_64.tbz.rmd160 from 
https://packages.macports.org/qt4-mac

The second step succeeded, i.e. MacPorts itself downloaded an inappropriate 
package for an Apple
Silicon machine. I noticed that some (maybe not all) of qt4-mac’s dependencies 
were compiled or
downloaded as arm64 code and, curiously, some of Qt4’s utility apps work on my 
machine, perhaps
due to the Rosetta emulator stepping in and taking over.

The kdelibs4 install failed in the “Computing dependencies…” step, saying 
“Error: Cannot install kdelibs4 for
the arch arm64 because its dependency qt4-mac only supports the archs ‘ppc 
ppc64 i386 x86_64’”

Is this a bug or is it the end of the line for kdelibs4 on arch64? Can kdelibs4 
really build as arch64? And what
about its (enormous) list of other dependencies? Do they all build for arch64?

If there is a bug here, I think it is that MacPorts can download a package for 
an inappropriate architecture.

Best regards,
Ian Wadham.

Re: Files and Folders access

[Ian Wadham]

I have had two similar issues, but with Catalina. One where Gimp (from the Gimp 
website, not Macports) would not save a file to my Desktop and the other where 
Apple’’s Screenshot facility (Command-Shift-4) would not save to it, although 
it had always done so automatically in High Sierra and earlier O/Ss. I got onto 
Apple Support’s chat line about the first, and they suggested to upgrade my 
Gimp, which I did and it worked.

The failure to save a screenshot to my Desktop actually occurred during the 
chat with Apple, but I was unable to investigate at the time. A day later I 
wanted to take a screenshot and send it by email. Same problem. All the usual 
Unix permissions on my Desktop seemed fine, but there is a new extension called 
“com.apple.macl” which works some kind of magic (ls -@ld ~/Desktop to see it). 
Nothing I did at the command-line could fix the problem with my Desktop.

Eventually I found the “approved” method of making my own Desktop accessible to 
me again.

1. Bring up a Finder window.
2. in the left-hand column, right-click on “Desktop” and select “Get Info” 
from the popup menu.
3. Scroll to the bottom of the Info window and click on the tiny “lock” 
icon.
4. When requested, enter your Admin password.
5. Click on “+”. A window listing Users and Groups should appear.
6. Select one (e.g. yourself). This should now appear in the Info window’s 
list, with Privilege “Read only".
7. Click on the Privilege and select “Read & Write” from the popup list.
8. Click on the little “lock” again, to close it.

Not exactly “intuitive”… I would say. Also Apple’s action regarding my Desktop, 
when it installed Catalina for me, is rather like a builder calling at my house 
to do some work, then changing the lock on my front door in the process, not 
telling me about this and then not leaving me a new key. I believe Apple’s 
intentions are still good, but they are becoming careless of their users’ 
interests. That works against them because I thought at first that they are 
becoming like IBM in the "bad old days” of the 60s and 70s. I thought they were 
trying to “influence" me to use only Apple products on my computer.

Re Gimp, I now have Gimp 2.10.28 from Gimp’s website. It has been upgraded to 
follow Apple’s latest security protocol. The first time I asked it to save to 
my Desktop, I got a dialog box asking permission and requiring an Admin 
password. After that it has been fine and is now on the list of “approved” 
applications in System Preferences->Security and Privacy->Privacy->Files and 
Folders.

Hope some of this helps.
Ian Wadham.

> On 17 Dec 2021, at 4:33 am, Lenore Horner  wrote:
> 
> I’m still struggling with letting Inkscape (I think Gimp too) installed via 
> MacPorts to be able to open files.  I’ve searched the mailing list archive 
> for the last year for any mention of this and found zip so apparently I’m 
> particularly incompetent.  Here’s what I’ve tried.
> 
> Big Sur 11.6
> MacPorts base 2.7.1
> Just updated the tree and all anything listed as outdated.
> inkscape-app @0.92_1, inkscape @0.92.5_9_x11, and xorg-server @1.20.11_1  
> installed and active
> r
> In Apple -> System Preferences -> Security and Privacy -> Files and Folders I 
> cannot do any thing even having unlocked with an admin password.
> In Apple -> System Preferences -> Security and Privacy -> Full Disk Access I 
> have given the following access the following:
> Inkscape (the terminal app found with Show Contents in the Inkscape.app file 
> in my MacPorts folder)
> Xquartz
> Terminal
> X11.app
> Inkscape.app (the Inkscape icon in the MacPorts folder)
> 
> I’ve shut down and restarted the computer and I’m still getting  "Could not 
> read the contents of Desktop” and a parallel complaint for Documents.  I know 
> that a dialog box should pop up asking for my permission to access my 
> Desktop, Documents, etc. folder and that those dialogs not popping up is a 
> known (and unfixible I think) issue.  I thought granting full disk access was 
> the only known work-around, but full disk access to what?   
> 
> I have, by the way also tried the dmg from the Inkscape website for version 
> 1.1.1.  I don’t get error messages with it, but it also can’t open a file 
> (spinning beachball of death). So that’s not good either.  
> 
> Thanks,
> Lenore

Re: ruby_select is broken

[Ian Wadham]

Thank you, Lenore.

> On 10 Oct 2021, at 1:45 am, Lenore Horner  wrote:
> 
> It looks to me like the actual problem is that ruby30 doesn’t produce any 
> notes about how to use port select unlike the pythonxx installations.  I’ve 
> filed a trac ticket about adding a note to ruby so that other people won’t 
> have Ian’s problem.
> Lenore
> 
>> On Oct 8, 2021, at 22:20, Ian Wadham  wrote:
>> 
>> Hi Ryan and Bill,
>> 
>> Let’s all stand back a bit and get a little perspective.
>> 
>> Firstly, the “sudo port select” command works fine, but it can take a while 
>> for a user to discover it when he/she needs it.
>> 
>> A few weeks ago I read about a package called Flutter and its underlying 
>> language called Dart. They are supplied freely and openly by Google. Their 
>> libraries, tools, code fragments and language are claimed to make it 
>> possible to write GUI applications that can run on almost any device, using 
>> the same source code for every device. Flutter can be used on Linux and 
>> Windows to build apps for Android devices or for Windows/Linux desktops. It 
>> can be used on MacOS to build apps for iPhones, iPads and the MacOS desktop. 
>> I live Melbourne, Australia, a city that has just established a world record 
>> for days in COVID lockdown. So I was anxious to relieve the boredom by 
>> trying out Flutter and Dart.
>> 
>> I have been a developer for many years and have many languages under my 
>> belt, but alas not Ruby.
>> 
>> Flutter’s pre-requisites on MacOS are Xcode 12 and CocoaPods. The latter 
>> depends on Ruby. I had to upgrade my MacOS from High Sierra to Catalina to 
>> get Xcode 12, which in itself was quite a drama, but I migrated MacPorts and 
>> my MacPorts apps without any trouble. 
>> 
>> The Getting Started page on CocoaPods’ website says to use Ruby as provided 
>> by MacOS, using command "sudo gem install cocoapods”. But that does not work 
>> and will never work again, because the MacOS version of Ruby is too old for 
>> building CocoaPods and is going to be phased out anyway in later versions of 
>> MacOS, as mentioned in the Catalina Release Notes.
>> 
>> As noted above, I was a complete newcomer to Ruby (and still am). I did not 
>> wish to learn Ruby. I just wanted to install a more recent version of Ruby 
>> in order to build CocoaPods and then move on to Flutter and Dart 
>> programming, starting with (you guessed it) Hello World.
>> 
>> When I installed the MacPorts package called “ruby” I got a version that was 
>> even more out-of-date than Apple’s (1.8 versus 2.6). When I installed the 
>> MacPorts package called “ruby27” I got nothing I could run: no “gem” command 
>> down in /opt/local/bin, so I uninstalled ruby27 and went looking elsewhere 
>> for a Ruby installer (Google, Stack Overflow, Homebrew, RVM, rbenv), but 
>> always I had the nagging thought that surely MacPorts would not install a 
>> package and then have no way you could use it. I had of course never heard 
>> of and never used the “port select” command at that stage. Why would I have? 
>> Until recently I have been a C++ developer.
>> 
>> Anyway I re-installed ruby27 and did a bit of digging around, finding that 
>> gem had been installed in /opt/local/bin as gem2.7, so I ran the command 
>> “gem2.7" and CocoaPods built and installed just fine. Then I wondered how 
>> does MacPorts handle other languages with multiple versions: I never had a 
>> problem a few years back when I downloaded a Python source program from the 
>> Internet and ran it, after using MacPorts to install Python. So I had a look 
>> at python_select’s portfile and discovered the existence of the “port 
>> select” command. Even then it is not easy to find. There are about a dozen 
>> occurrences of the word “select” in the “man port” output and I was 
>> wondering for a moment if “port select” actually exists or if it is just 
>> some internal function of portfiles and MacPorts scripts.
>> 
>> All of the above occupied several frustrating days of my time.
>> 
>> So this is why I say the portfile for ruby_select is broken. Several 
>> “ruby$NN” packages depend on it.
>> 
>> MacPorts’ Python gives a new user something he/she can immediately use, with 
>> a sensible default version being automatically “selected” (in the MacPorts 
>> sense), but MacPorts’ Ruby does not do any of that. So it fails on the 
>> grounds of user UN-friendliness. At the very least MacPorts’ Ruby 
>> installations should have a Note to inform any new users about the “port 
>> select” co

Re: ruby_select is broken

[Ian Wadham]

Hi Ryan and Bill,

Let’s all stand back a bit and get a little perspective.

Firstly, the “sudo port select” command works fine, but it can take a while for 
a user to discover it when he/she needs it.

A few weeks ago I read about a package called Flutter and its underlying 
language called Dart. They are supplied freely and openly by Google. Their 
libraries, tools, code fragments and language are claimed to make it possible 
to write GUI applications that can run on almost any device, using the same 
source code for every device. Flutter can be used on Linux and Windows to build 
apps for Android devices or for Windows/Linux desktops. It can be used on MacOS 
to build apps for iPhones, iPads and the MacOS desktop. I live Melbourne, 
Australia, a city that has just established a world record for days in COVID 
lockdown. So I was anxious to relieve the boredom by trying out Flutter and 
Dart.

I have been a developer for many years and have many languages under my belt, 
but alas not Ruby.

Flutter’s pre-requisites on MacOS are Xcode 12 and CocoaPods. The latter 
depends on Ruby. I had to upgrade my MacOS from High Sierra to Catalina to get 
Xcode 12, which in itself was quite a drama, but I migrated MacPorts and my 
MacPorts apps without any trouble. 

The Getting Started page on CocoaPods’ website says to use Ruby as provided by 
MacOS, using command "sudo gem install cocoapods”. But that does not work and 
will never work again, because the MacOS version of Ruby is too old for 
building CocoaPods and is going to be phased out anyway in later versions of 
MacOS, as mentioned in the Catalina Release Notes.

As noted above, I was a complete newcomer to Ruby (and still am). I did not 
wish to learn Ruby. I just wanted to install a more recent version of Ruby in 
order to build CocoaPods and then move on to Flutter and Dart programming, 
starting with (you guessed it) Hello World.

When I installed the MacPorts package called “ruby” I got a version that was 
even more out-of-date than Apple’s (1.8 versus 2.6). When I installed the 
MacPorts package called “ruby27” I got nothing I could run: no “gem” command 
down in /opt/local/bin, so I uninstalled ruby27 and went looking elsewhere for 
a Ruby installer (Google, Stack Overflow, Homebrew, RVM, rbenv), but always I 
had the nagging thought that surely MacPorts would not install a package and 
then have no way you could use it. I had of course never heard of and never 
used the “port select” command at that stage. Why would I have? Until recently 
I have been a C++ developer.

Anyway I re-installed ruby27 and did a bit of digging around, finding that gem 
had been installed in /opt/local/bin as gem2.7, so I ran the command “gem2.7" 
and CocoaPods built and installed just fine. Then I wondered how does MacPorts 
handle other languages with multiple versions: I never had a problem a few 
years back when I downloaded a Python source program from the Internet and ran 
it, after using MacPorts to install Python. So I had a look at python_select’s 
portfile and discovered the existence of the “port select” command. Even then 
it is not easy to find. There are about a dozen occurrences of the word 
“select” in the “man port” output and I was wondering for a moment if “port 
select” actually exists or if it is just some internal function of portfiles 
and MacPorts scripts.

All of the above occupied several frustrating days of my time.

So this is why I say the portfile for ruby_select is broken. Several “ruby$NN” 
packages depend on it.

MacPorts’ Python gives a new user something he/she can immediately use, with a 
sensible default version being automatically “selected” (in the MacPorts 
sense), but MacPorts’ Ruby does not do any of that. So it fails on the grounds 
of user UN-friendliness. At the very least MacPorts’ Ruby installations should 
have a Note to inform any new users about the “port select” command.

All’s well that ends well. I am now getting up to speed on Flutter and Dart and 
have run the demo source code on my MacBook desktop and on an Xcode Simulator 
of my iPhone. I am also progressing well on porting one of my C++ apps to 
Flutter and Dart.

All the best,
Ian Wadham.

> On 6 Oct 2021, at 8:54 am, Ryan Schmidt  wrote:
> On Oct 3, 2021, at 02:58, Ian Wadham wrote:
>> On 2 Oct 2021, at 6:29 pm, Ryan Schmidt wrote:
>>> On Sep 25, 2021, at 23:14, Ian Wadham wrote:
>>> 
>>>> MacPorts contains packages of many versions of Ruby, similarly to the 
>>>> Python and Perl groups, but the corresponding “ruby_select” port does not 
>>>> automatically create the links needed to access commands “ruby”, “gem” 
>>>> etc. I was able to get around this by using “sudo port select” manually, 
>>>> but would it be possible for someone to fix “ruby_select” so that the 
>>>> ports “ruby$n” work properly “out of the box".
>>> 
>>> I don'

Re: ruby_select is broken

[Ian Wadham]

Hi Christopher,

In brief, MacPorts’ “port select” command is working fine at the command-line 
in Catalina… but the problem is with installing ANY version of ruby, not 
switching between multiple versions of ruby that are already installed.

In a machine where no MacPorts Ruby is installed, the command “sudo port 
install ruby27” is not working fully.

The package gets installed, but the links /opt/local/bin/ruby -> 
/opt/local/bin/ruby2.7 and /opt/local/bin/gem -> /opt/local/bin/gem2.7 do not 
get created automatically. So after installing I always get Apple’s Ruby from 
/usr/bin when I use a “ruby” or “gem” command. Of course I can use “sudo port 
select” to fix that, and I have done, but it took me several days of 
frustration and messing around before I discovered that fact.

I think this is because the port file named “ruby_select”, on which each Ruby 
port depends, is broken. You can see this port file’s contents using:

 cat $(port file ruby_select)

Compare them to the perl and python “select” files:

 cat $(port file perl_select)
 cat $(port file python_select)

and I hope you (or someone) will see what the problem is.

Cheers,
Ian Wadham.

> On 4 Oct 2021, at 1:12 am, Christopher Nielsen  
> wrote:
> 
>> The ruby_select portile just has:
>> 
>> destroot {
>>  select::install ruby ${filespath}/base
>>  select::install ruby ${filespath}/none
>> }
>> 
>> which does not redirect the commands “ruby” or “gem” to the appropriate 
>> version when you have installed the port “ruby27” for example. Instead, 
>> “which ruby” or “which gem” always finds the Apple version of Ruby, which is 
>> now deprecated according to the Catalina Release Notes…
> 
> Hmmm, it’s working fine for me.
> 
> Starting from the default case, where nothing has been selected yet:
> 
> $ ll $(which ruby)
> -r-xr-xr-x  1 root  wheel  restricted,compressed   51K Jul  9 18:40:13 2020 
> /usr/bin/ruby
> $ ll $(which gem)
> -r-xr-xr-x  1 root  wheel  restricted,compressed  596B Jul 15 17:58:00 2017 
> /usr/bin/gem
> 
> After selecting ruby30:
> 
> $ sudo port select ruby ruby30
> Selecting 'ruby30' for 'ruby' succeeded. 'ruby30' is now active.
> $ ll $(which ruby)
> lrwxr-xr-x  1 root  admin  -   22B Oct  3 09:54:35 2021 /opt/local/bin/ruby 
> -> /opt/local/bin/ruby3.0
> $ ll $(which gem)
> lrwxr-xr-x  1 root  admin  -   21B Oct  3 09:54:35 2021 /opt/local/bin/gem -> 
> /opt/local/bin/gem3.0
> 
> After selecting ruby27:
> 
> $ sudo port select ruby ruby27
> Selecting 'ruby27' for 'ruby' succeeded. 'ruby27' is now active.
> $ ll $(which ruby)
> lrwxr-xr-x  1 root  admin  -   22B Oct  3 09:55:14 2021 /opt/local/bin/ruby 
> -> /opt/local/bin/ruby2.7
> $ ll $(which gem)
> lrwxr-xr-x  1 root  admin  -   21B Oct  3 09:55:14 2021 /opt/local/bin/gem -> 
> /opt/local/bin/gem2.7
> 
> And finally, after reverting back to no selection:
> 
> $ sudo port select ruby none
> Selecting 'none' for 'ruby' succeeded. 'none' is now active.
> $ ll $(which ruby)
> -r-xr-xr-x  1 root  wheel  restricted,compressed   51K Jul  9 18:40:13 2020 
> /usr/bin/ruby
> $ ll $(which gem)
> -r-xr-xr-x  1 root  wheel  restricted,compressed  596B Jul 15 17:58:00 2017 
> /usr/bin/gem
> 
> So this isn’t working for you on macOS Catalina…?

Re: How to get a developers' package for Ruby

[Ian Wadham]

> On 2 Oct 2021, at 6:33 pm, Ryan Schmidt  wrote:
> 
> On Sep 21, 2021, at 23:49, Ian Wadham wrote:
> 
>> I wish to download from the Web a package called CocoaPods, however it needs 
>> a developers’ package of Ruby to build it.
>> 
>> I am using MacOS Catalina 10.15.7. Apple provides Ruby in this MacOSversion, 
>> but will not allow it to be used for building non-Apple apps. They say they 
>> are phasing out the use of Ruby in MacOS and Apple Mac apps.
>> 
>> Googling around about this problem, all the solutions I have found recommend 
>> getting a "ruby-dev" package from Homebrew, but MacPorts, which I use a lot, 
>> recommends against mixing MacPorts and Homebrew.
> 
> Some other package managers observe a distinction between "runtime" and 
> "development" packages, with the latter having a "-dev" suffix. MacPorts does 
> not observe such a distinction. All packages in MacPorts contain both the 
> runtime and development parts, to the extent that each software package has 
> those parts.

I have since found out that all Ruby packages have facilities for developing 
programs or running existing programs, including MacPorts’ “ruby” and “ruby$NN” 
packages. The command “gem” is used to build and install Ruby programs. I have 
used the “ruby27” port to build and install CocoaPods successfully, I am 
pleased to say, which was my primary objective.

> MacPorts does have port names with a "-devel" suffix, but they embody a 
> completely unrelated concept. Ports with names not ending with "-devel" are 
> typically for stable versions of software while ports with the "-devel" name 
> suffix are for newer unstable versions.
> 
>> Failing that, would it be safe to install Homebrew and its ruby-dev, just 
>> for building CocoaPods?
> 
> Please choose one package manager and uninstall the other. We do not want to 
> spend time diagnosing problems that were caused by installing software with 
> multiple conflicting package managers.

It turns out that MacPorts Ruby packages do not work “out of the box” because 
the “ruby_select” port file is not doing its job (see “ruby_select is broken” 
thread). I used a “port select” command to complete the installation correctly.

Homebrew’s Ruby was recommended on Stack Overflow and elsewhere, but it 
provides only the latest Ruby. Besides I have other packages I use on MacPorts 
and won’t be going anywhere else in a hurry. There are also several Ruby 
installers such as rbenv or RVM, which might have been my next port of call if 
I had not not gotten a MacPorts’ Ruby installed.

Thanks, Ryan.
Ian Wadham.

Re: ruby_select is broken

[Ian Wadham]

> On 2 Oct 2021, at 6:29 pm, Ryan Schmidt  wrote:
> On Sep 25, 2021, at 23:14, Ian Wadham wrote:
> 
>> MacPorts contains packages of many versions of Ruby, similarly to the Python 
>> and Perl groups, but the corresponding “ruby_select” port does not 
>> automatically create the links needed to access commands “ruby”, “gem” etc. 
>> I was able to get around this by using “sudo port select” manually, but 
>> would it be possible for someone to fix “ruby_select” so that the ports 
>> “ruby$n” work properly “out of the box".
> 
> I don't understand what you mean. ruby_select (and all _select ports) are 
> helper infrastructure so that "port select" works. Using "port select" is not 
> a workaround; it is *the* way to select a particular version of a set of 
> ports.

The helper infrastructure is failing for ports “ruby$NN”. Other ports which 
have multiple versions available have lines like:

platform darwin 14 {
post-destroot {
select::install perl ${filespath}/perl5.16-apple.14
select::install perl ${filespath}/perl5.18-apple.14
}
}

or

foreach python $apple_pythons {
select.entries-append [list python {*}$python]
}

in their *_select portfiles. Presumably these automate the redirecting of 
commands such as “perl' or “python" to the appropriate version.

The ruby_select portile just has:
  
destroot {
  select::install ruby ${filespath}/base
  select::install ruby ${filespath}/none
}

which does not redirect the commands “ruby” or “gem” to the appropriate version 
when you have installed the port “ruby27” for example. Instead, “which ruby” or 
“which gem” always finds the Apple version of Ruby, which is now deprecated 
according to the Catalina Release Notes...

Actually my first “workaround" was to use a Bash alias, but then I figured 
there must be a MacPorts command to fix it, perhaps called “port select”… :-)

In any event, the portile for ruby_select is not working on ports like 
“ruby26”, “ruby27”, etc.

>> Also, the port actually called “ruby” is very old (version 1.8.7) and “port 
>> notes ruby” deprecates it. Should it be removed from MacPorts?
> 
> If nobody needs it, I suppose it could be removed. Do you know that nobody 
> needs it? I don't know that.
> 
>> Or reincarnated as “ruby18”, dropping “ruby186” as well?
> 
> If it ain't broke, don't fix it?

Port “ruby_select” is broken.

Port “ruby” wasted my time because it looked as though it would be the default 
one to install, but then at the end of installation it deprecated itself.

Cheers,
Ian Wadham.

Re: Does MacPorts need ALL of Xcode?

[Ian Wadham]

> On 2 Oct 2021, at 6:20 pm, Ryan Schmidt  wrote:
> 
> On Sep 27, 2021, at 16:36, Ian Wadham wrote:
> 
>> So what is the “recipe” to install just the CLT with no version of Xcode 
>> present? And can that recipe be included in the MacPorts Guide?
> 
> Run
> 
> xcode-select --install
> 
> and click the button to install the command line tools.
> 
> Or download the command line tools installer from the Apple Developer 
> Downloads web site.

OK, thanks Ryan, but how about https://guide.macports.org/#installing.xcode ?

It explicitly says to install Xcode first, as a dependency of MacPorts, and 
then do xcode-select —install, which is what I have been doing for 10 years or 
more as a MacPorts user. And I suppose almost all other MacPorts users have too.

But in that time Xcode has grown from a gigabyte or two to 20 Gb on my current 
MacOS, Catalina 10.15.7. That is a significant slice of the SSD storage in a 
shop-standard MacBook Pro. So if a user does not need Xcode as a prerequisite 
of MacPorts, he/she should not have to carry the time and space overheads of 
downloading, installing and storing it.

My question then is please can https://guide.macports.org/#installing.xcode be 
re-written to help users who do not need Xcode for any other reason?

>> Couldn’t those ports list Xcode as a build dependency?
> 
> They do, by using this keyword:
> 
> use_xcode yes

Chris Jones raised the point on 26/27 September on this thread that some ports 
require Xcode and gave this as the reason for MacPorts requiring Xcode.

But how many ports are involved here? What percentage of users are likely to 
need them? And what is the worst that can happen to a user if he/she happens to 
run into one and does not have Xcode installed?

I tried port search use_xcode to try and shed some light on these questions, 
but it gave "no match … found”.

Cheers,
Ian Waham.

Re: Does MacPorts need ALL of Xcode?

[Ian Wadham]

Hello Chris,

> On 27 Sep 2021, at 8:42 am, Chris Jones  wrote:
> The majority of ports will indeed build fine with just the CLT installed.

So what is the “recipe” to install just the CLT with no version of Xcode 
present? And can that recipe be included in the MacPorts Guide?

> There are a number though where the build does indeed require a complete 
> Xcode installation, which is why the baseline recommendation is to install 
> Xcode. However if you are ok with perhaps running into the occasional port 
> failure (the likelihood for which depends on which ports you use) you likely 
> can get by just fine with just the CLT.

Couldn’t those ports list Xcode as a build dependency?

If a dependency has to be another MacPorts package, then perhaps there could be 
a dummy Xcode in MacPorts, maybe just a Portfile, that checks the presence and 
version of the Xcode.app.

Otherwise, new MacPorts users may be paying a 20Gb disk storage penalty forever 
more. And the time to download and install Xcode could become a disincentive 
for new MacPorts users in any case…

Cheers, Ian Wadham.

> Chris
> 
>> On 26 Sep 2021, at 10:07 am, Mircea Trandafir  wrote:
>> 
>>  I’ve been using only the command line tools for more than a year with 
>> absolutely no issues (other than the occasional “version not detected” 
>> error, but I think that happens with Xcode too).
>> 
>> -- 
>> Mircea Trandafir
>> Associate professor
>> Department of Economics
>> University of Southern Denmark
>> Campusvej 55, 5230 Odense M
>> Denmark
>> Email: mircea.tranda...@sam.sdu.dk
>> Web: http://www.mirceatrandafir.com
>> 
>>> On Sep 26, 2021, at 5:52 AM, Ian Wadham  wrote:
>>> 
>>> Hi guys,
>>> 
>>> I have recently upgraded my MacOS from High Sierra 10.13 to Catalina 10.15, 
>>> mainly because I would like to start playing with a package called Flutter, 
>>> which has a dependency on Xcode 12+ in its MacBook version.
>>> 
>>> It appears that Xcode is following some variant of Grosch’s Law, or maybe 
>>> Parkinson’s Law (software expands to fill the hardware space available to 
>>> it). So I am wondering, if all a user needs are some MacPorts packages, 
>>> whether it is necessary to install all (or even any) of Xcode just to get 
>>> the command-line tools.
>>> 
>>> I have been using MacPorts to get access to FOSS for more than 10 years and 
>>> have watched the Xcode requirement grow from around 1 Gb of disk to around 
>>> 20 Gb in Catalina. In Xcode 9, on High Sierra, the requirement was around 
>>> 10 Gb. So it has roughly doubled in two version steps of MacOS.
>>> 
>>> At first I used to regard the Xcode overhead as being like some sort of tax 
>>> on the pleasure of using FOSS, but now it is taking up an unhealthy portion 
>>> of the 250 Gb in my MacBook Pro’s 250 Gb internal SSD drive.
>>> 
>>> I have to put up with this if I wish to use Macports and Flutter, even 
>>> though, like Dave Horsfall, I am unlikely to use Xcode as an IDE. So is it 
>>> possible to have MacPorts depend on some minimal subset of Xcode?
>>> 
>>> Cheers,
>>> Ian Wadham.
>>> 

ruby_select is broken

[Ian Wadham]

Hi guys,

MacPorts contains packages of many versions of Ruby, similarly to the Python 
and Perl groups, but the corresponding “ruby_select” port does not 
automatically create the links needed to access commands “ruby”, “gem” etc. I 
was able to get around this by using “sudo port select” manually, but would it 
be possible for someone to fix “ruby_select” so that the ports “ruby$n” work 
properly “out of the box".

Also, the port actually called “ruby” is very old (version 1.8.7) and “port 
notes ruby” deprecates it. Should it be removed from MacPorts? Or reincarnated 
as “ruby18”, dropping “ruby186” as well?

Cheers,
Ian Wadham.

Does MacPorts need ALL of Xcode?

[Ian Wadham]

Hi guys,

I have recently upgraded my MacOS from High Sierra 10.13 to Catalina 10.15, 
mainly because I would like to start playing with a package called Flutter, 
which has a dependency on Xcode 12+ in its MacBook version.

It appears that Xcode is following some variant of Grosch’s Law, or maybe 
Parkinson’s Law (software expands to fill the hardware space available to it). 
So I am wondering, if all a user needs are some MacPorts packages, whether it 
is necessary to install all (or even any) of Xcode just to get the command-line 
tools.

I have been using MacPorts to get access to FOSS for more than 10 years and 
have watched the Xcode requirement grow from around 1 Gb of disk to around 20 
Gb in Catalina. In Xcode 9, on High Sierra, the requirement was around 10 Gb. 
So it has roughly doubled in two version steps of MacOS.

At first I used to regard the Xcode overhead as being like some sort of tax on 
the pleasure of using FOSS, but now it is taking up an unhealthy portion of the 
250 Gb in my MacBook Pro’s 250 Gb internal SSD drive.

I have to put up with this if I wish to use Macports and Flutter, even though, 
like Dave Horsfall, I am unlikely to use Xcode as an IDE. So is it possible to 
have MacPorts depend on some minimal subset of Xcode?

Cheers,
Ian Wadham.

Re: How to get a developers' package for Ruby

[Ian Wadham]

Hi Jose and thank you for your reply.

> On 22 Sep 2021, at 3:05 pm, Jose Hales-Garcia  wrote:
> Hi,
> You might see if Rbenv would work for you in this case.
> https://github.com/rbenv/rbenv
> 
> I googled and there are folks who’ve gotten cocoapods working with rbenv 
> installed Ruby versions.

I did some googling around before starting this thread, but I have done some 
more googling around now and also some digging deeper into MacPorts.

I have found that I can get any of several versions of Ruby and its development 
tools (gem, etc) from MacPorts, so I won’t be needing rbenv at the moment, nor 
any of the other Ruby installers such as RVM or Homebrew's ruby-dev.

The trac tickets for CocoaPods and discussions in CocoaPods' StackOverflow area 
gave me some leads. It turns out that the deprecation warning in Apple’s 
Release Notes for Catalina, regarding Ruby, Python and Perl, was a red herring 
for me, although it is true that Apple will withdraw runtime support for those 
languages eventually. See 
https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes.

The real problem I have been fighting all along is simply that the version of 
Ruby and its development tools in Catalina is too old to build the current 
version of CocoaPods and also that my build failed with a whole lot of 
unreadable diagnostics. Not good for a “Getting Started” situation...

It also did not help that MacPorts' “ruby_select” port is broken, so I was 
previously unable to find a “gem” executable in MacPorts’ “rubyNN” packages, 
which depend on "ruby_select". I got around that when I ran across the “port 
select” command and used it to form the needed links to “ruby”. “gem”, etc.

Anyway, I have now used MacPorts’ Ruby to build CocoaPods and satisfy the 
Flutter package’s dependencies in a MacOS environment.

And I can now answer my own questions (see below if interested).

> Jose
> 
>> On Sep 21, 2021, at 9:49 PM, Ian Wadham  wrote:
>> 
>> I wish to download from the Web a package called CocoaPods, however it 
>> needs a developers’ package of Ruby to build it.
>> 
>> I am using MacOS Catalina 10.15.7. Apple provides Ruby in this MacOSversion, 
>> but will not allow it to be used for building non-Apple apps. They say they 
>> are phasing out the use of Ruby in MacOS and Apple Mac apps.

Apple’s Ruby in Catalina does still have runtime support, but Ruby, Python and 
Perl will disappear from MacOS eventually.
See 
https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes

>> 
>> Googling around about this problem, all the solutions I have found recommend 
>> getting a "ruby-dev" package from Homebrew, but MacPorts, which I use a lot, 
>> recommends against mixing MacPorts and Homebrew.
>> 
>> Apple’s version of Ruby is ruby 2.6.3p62 (2019-04-16 revision 67580).

This is too old to build the current version of CocoaPads, but I have been able 
to build it using MacPorts “ruby27” and a manual “port select” command.

>> MacPorts has a package ruby @1.8.7-p374_12 (lang, ruby), but also packages 
>> ruby26 @2.6.8_1 (lang, ruby), ruby27 @2.7.4_1 (lang, ruby), etc. Are all of 
>> these development versions, or just runtime versions? If MacPorts has a 
>> development version of Ruby, which would be the best version to use to build 
>> CocoaPods?

All Macports’ “rubyNN” packages can be used for development and runtime AFAICS, 
but “ruby_select” is broken and you need to use “port select” manually.

>> Failing that, would it be safe to install Homebrew and its ruby-dev, just 
>> for building CocoaPods?

No need, but MacPorts’ “ruby_select” needs fixing, to work similarly to 
“python_select” and “perl_select”.

Cheers,
Ian Wadham.

Re: What version of Xcode for High Sierra?

[Ian Wadham]

This link has a comprehensive list of Xcode release and pre-release versions… 
https://xcodereleases.com/

They are tabulated with dependencies on OS’s and links to downloads and release 
notes.

> On 25 Sep 2021, at 11:59 am, Bill Cole 
>  wrote:
> 
> On 2021-09-24 at 19:18:56 UTC-0400 (Sat, 25 Sep 2021 09:18:56 +1000 (EST))
> Dave Horsfall 
> is rumored to have said:
> 
>> MacBook Pro, 13", mid-2010, 8GB memory (self-supplied, as the default 4GB is 
>> simply not enough), firmware 7,1.
>> 
>> Relevance to MacPorts: it needs Xcode...
>> 
>> There seems to be many versions of Xcode for High Sierra (I don't want to 
>> upgrade further just yet) so which one is known to work for this thing so 
>> that I can start using MacPorts again??  I don't want to waste a few hours 
>> of download (including Command Line Tools) only to see "xcode-select" spit 
>> the dummy because it's the wrong version of the OS or something.
> 
> 10.1 or 9.4.1 should work. Supposedly one can install 10.2 by hacking some 
> plist and it will work, but that would be silly if all you really need it for 
> is MacPorts.

I would suggest 9.4.1 because it will require a few Gb less disk space.

Cheers,
Ian Wadham.

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

How to get a developers' package for Ruby

[Ian Wadham]

I wish to download from the Web a package called CocoaPods, however it needs a 
developers’ package of Ruby to build it.

I am using MacOS Catalina 10.15.7. Apple provides Ruby in this MacOSversion, 
but will not allow it to be used for building non-Apple apps. They say they are 
phasing out the use of Ruby in MacOS and Apple Mac apps.

Googling around about this problem, all the solutions I have found recommend 
getting a "ruby-dev" package from Homebrew, but MacPorts, which I use a lot, 
recommends against mixing MacPorts and Homebrew.

Apple’s version of Ruby is ruby 2.6.3p62 (2019-04-16 revision 67580).

MacPorts has a package ruby @1.8.7-p374_12 (lang, ruby), but also packages 
ruby26 @2.6.8_1 (lang, ruby), ruby27 @2.7.4_1 (lang, ruby), etc. Are all of 
these development versions, or just runtime versions? If MacPorts has a 
development version of Ruby, which would be the best version to use to build 
CocoaPods?

Failing that, would it be safe to install Homebrew and its ruby-dev, just for 
building CocoaPods?

I have no intention of learning Ruby for my own development use at this stage.

Hoping someone can point me in the right direction,
Thanks in advance,
Ian Wadham.

Re: macOS 11 Big Sur and MacPorts

[Ian Wadham]

> On 30 Aug 2021, at 6:30 am, Dave Horsfall  wrote:
>>> Thanks for the heads-up; I think my MacBook Pro will be stuck forever on 
>>> Sierra 10.12.6 (although admittedly I haven't tried High Sierra on this 
>>> one) and MacPorts 2.6.3 is likely as far as it will go.
> 
> I successfully installed High Sierra; I needed it to drive a multi-function 
> printer that I acquired.

The pressures that prompt us to upgrade the O/S… :-)

FWIW I have been on High Sierra for ages, but a few days ago I was unable to 
upload a PDF document to a certain Australian Government website, with severe 
financial penalties if I failed to provide the document within 3 weeks. Apple's 
Telephone Support and I figured out a workaround (an image of the document in 
JPG format), but their chief recommendation was to upgrade to Mojave, Catalina 
or Big Sur, to take advantage of major upgrades to Safari… Actually I use 
Firefox, but I think it has to go via Safari for some functions… I had to 
temporarily switch to Safari to prove to Apple Support that the problem is not 
in Firefox.

Cheers,
Ian Wadham.

Re: Fixing source-code bugs using MacPorts facilities.

[Ian Wadham]

> On 29 Jul 2020, at 2:27 pm, Ken Cunningham  
> wrote:
> 
>> On Jul 28, 2020, at 9:22 PM, Ian Wadham  wrote:
> 
>> Also, Ken, I have worked out a way of maintaining a git repository of the 
>> source code and edits that is external to MacPorts and entirely under my 
>> control, so the need to avoid “install” is not so great. The compromise is 
>> that, after a bunch of edits, I will be using a script I wrote called  
>> “./ship” to copy the changed files down into MacPorts’ 
>> work/ area, after editing and before (re)building and 
>> testing.
> 
> 
> If you get that to a sharable state, pls post it up so I can have a look.

There’s nothing much to write home about.

Basically I have in my /kdedev/ports/kde/kpat portfile directory:

files/portfile  rebuild*  repo/ work@

I just used mkdir to create repo/, then populated it using something like:

cp -R work/kpat-4.14.3/ repo

The ending slash on the source files of cp -R make it blatt all the files and 
subdirs into repo/ without creating a new kpat-4.14.3/ subdir.

I then made repo/ into a git repository and added the script called “ship”.

At the moment, “ship” is just:

192-168-1-104:/kdedev/ports/kde/kpat>cat repo/ship
for f in $*
do
cp $f ../work/kpat-4.14.3/$f
echo "---" $f replaced in MacPorts
done

So I have to supply paths to recently edited files as parameters, but at least 
they can be validated by using bash filename completions. Another possibility 
is that I could use something like "git status --untracked-files=no —porcelain” 
to get a parseable list of changes and so automate the copying of recently made 
and not yet commited edits into MacPorts, within the script call “rebuild”.

The “rebuild script at present is:

192-168-1-104:/kdedev/ports/kde/kpat>cat rebuild
#
# Wind the MacPorts state-file back to just before "build" state.
sudo sed -e'/build/,$d' work/.macports.kpat.state >temp
sudo cp temp work/.macports.kpat.state
rm temp

# Re-build, using the most recently edited source code.
sudo port -v build
sudo port destroot

Note that “cp” only cares about “rwx” access rights, not ownership or group 
membership. If the target file exists, it changes the contents of that file, 
without changing its attributes. So the state-file and everything down in 
MacPorts retain owner, group and access rights whenever my scripts change their 
contents.

> I’ve been meaning to write something for a portfile to override the “extract” 
> and “patch” portfile phases to just symlink the source directory into the 
> work folder — come to think of it, that might be all I need to do — but 
> haven’t got around to it.
> 
> There are a few massive ports I work on:
> 
> qt4-mac
> qt5.N for various older systems
> llvm-N

Errrmmm I would worry about making anything as big as those into single git 
repositories.

In KDE, at least, every app or library is just one repository, but they are 
grouped into categories (e.g. “kpat” is part of “games”). See 
https://invent.kde.org/games/kpat on GitLab. I guess Qt can be broken up 
similarly, from my experience of it. Divide and conquer… :-)

> that would benefit from this approach rather than what I do now.

With git, I am looking forward to using branches, where I can create and 
evaluate alternate solutions to the bugs I am chasing. Also, until I merge 
branches, I think I can easily get back to base with git checkout master, e.g. 
to do "before and after" testing of fixes.

Cheers,
Ian W.

> Ken

Re: Fixing source-code bugs using MacPorts facilities.

[Ian Wadham]

> On 28 Jul 2020, at 8:06 pm, Ryan Schmidt  wrote:
> 
> On Jul 27, 2020, at 01:53, Ian Wadham wrote:
> 
>> I’m just saying that I can execute the file 
>> 'work/destroot/Applications/MacPorts/…/kpat’ instead of 
>> ‘/Applications/MacPorts/…/kpat’ — at the command-line of course.
> 
> That executable may link with libraries installed by the port. If so, the 
> executable would probably use the libraries at their installed location, not 
> at their destroot location. If you have an old version of the libraries 
> installed, that might cause problems. If you don't have the port installed at 
> all, you'll get library not found errors. The application may also look for 
> other data files at their installed location. All things considered, it's 
> less problematic to install the port and then use the installed files.
> 
Thanks, Ryan, point taken. I’ll be careful.

The risk is low, AFAICT, because all the source-code I am working with and 
dependent on, down to the level of Qt4, has been unchanged in MacPorts for 
several years, apart from tweaks to accommodate new versions of OSX. I am on 
High Sierra, but used to be on Lion back then.

Also, Ken, I have worked out a way of maintaining a git repository of the 
source code and edits that is external to MacPorts and entirely under my 
control, so the need to avoid “install” is not so great. The compromise is 
that, after a bunch of edits, I will be using a script I wrote called  “./ship” 
to copy the changed files down into MacPorts’ work/ area, 
after editing and before (re)building and testing.

Thanks very much to both of you, Ken and Ryan, for all your help.

All the best,
Ian W.

Re: Fixing source-code bugs using MacPorts facilities.

[Ian Wadham]

> On 27 Jul 2020, at 4:02 pm, Ken Cunningham  
> wrote:
> 
> 
> On 2020-07-26, at 10:30 PM, Ian Wadham wrote:
> 
> 
>> Ken’s final step — sudo port -v -k install — does not work, or maybe works 
>> only on the first cycle.
> 
> Yes, once the port is installed, you have to specifically uninstall it before 
> you can reinstall it again. 
> 
> MacPorts will not install it again overtop.. or come to think of it maybe it 
> will with the "-f" flag, haven't tried that...even so, I wouldn't really 
> trust that.
> 
> So far what I have done is uninstall the port (this does not affect your 
> build / work directory) and then run "install" again.

I’ll try that. Thanks.

>> Looking in /Applications/MacPorts/KDE4/kpat.app/Contents/MacOS/, the new 
>> executable (file kpat) does not get staged in from the …/destroot/… 
>> directory structure.
>> 
>> This is the only runtime file that I am actually changing and KDE 4 does not 
>> care where its executable files come from.
>> 
>> So I would be happy to test by running the kpat executable that appears in 
>> the …/destroot/… structure, unless you guys have a better way.
> 
> 
> I afraid I don't exactly follow the question here, but maybe Ryan does.

I’m just saying that I can execute the file 
'work/destroot/Applications/MacPorts/…/kpat’ instead of 
‘/Applications/MacPorts/…/kpat’ — at the command-line of course. I guess the 
only other way is as you have said above — uninstall and reinstall.

Re keeping the git repository, I guess I can just copy it out somewhere 
holus-bolus and put it back whenever I need to do some more work on KPat.

Nobody upstream is changing this KDE4 version of KPat code — it’s a snapshot. 
But I will need to take breaks of a few days, keeping my git repository safe, 
while I get my changes realigned to the latest KPat code’s line numbers, then 
reviewed and accepted into KDE's central repositories (KF5 versions) on GitLab. 

Cheers,
Ian W.

> 
> K
> 

Re: Fixing source-code bugs using MacPorts facilities.

[Ian Wadham]

Hi Ken and Ryan,

Thank you very much for your suggestions. I think I have got all of them 
working, including cycling repeatedly through editing the MacPorts version of 
source down in /opt/local/…, then cyling back through editing the state file, 
re-doing build and re-doing destroot.

There is just one fly in the ointment.

Ken’s final step — sudo port -v -k install — does not work, or maybe works only 
on the first cycle. Looking in 
/Applications/MacPorts/KDE4/kpat.app/Contents/MacOS/, the new executable (file 
kpat) does not get staged in from the …/destroot/… directory structure.

This is the only runtime file that I am actually changing and KDE 4 does not 
care where its executable files come from.

So I would be happy to test by running the kpat executable that appears in the 
…/destroot/… structure, unless you guys have a better way.

Cheers,
Ian W.

> On 26 Jul 2020, at 5:37 pm, Ken Cunningham  
> wrote:
> 
> 
> On 2020-07-25, at 11:26 PM, Ryan Schmidt wrote:
> 
>> 
>> 
>> On Jul 26, 2020, at 01:15, Ian Wadham wrote:
>> 
>>> The above all worked very well, but only once… :-(
>>> 
>>> If I test the app I have installed and find there is still some problem, I 
>>> need to edit the source and go back to the build step. But “build” just 
>>> says "--->  Computing dependencies for kpat”  and exits, even if I use 
>>> “sudo port -f build”. It does not see that the source has changed.
>> 
>> MacPorts keeps track of which phases have been completed. If you 
>> successfully build a port, for example, the build phase is marked completed 
>> and will not be attempted again until you clean and start over. 
>> 
>> To bypass that behavior, you can edit the state file (a file in the work 
>> directory whose name is .macports.${subport}.state) and remove lines from 
>> the end of it for completed phases that you want to retry.
>> 
> 
> 
> Indeed as Ryan said.
> 
> I wanted to let you see the basics, without overwhelming you.
> 
> Once you can do that, as Ryan points out, you can delete the destroot and/or 
> build folders, edit  the state file, and have MacPorts redo the steps you 
> want it to do.
> 
> You can also have macports just redo the destrooting without redoing the 
> build, editing the portfile, and passing "-o" to have it leave the build 
> alone -- I do this quite often for complex destrooting scenarios.
> 
> It is incredibly powerful, but it does miss one feature that I would really 
> like -- to be able to do this using a stable git repo on my system as the 
> source folder, rather than a transient one created for each build.
> 
> Ken
> 
> 

Re: Fixing source-code bugs using MacPorts facilities.

[Ian Wadham]

Thanks very much for your help, Ken.

> On 26 Jul 2020, at 3:31 am, Ken Cunningham  
> wrote:
> 
> Here is my process (courtesy of advice from many others on this list 
> including Chris and Michael and others). And this is not yet ideal, as no 
> doubt it could be further improved. This is for anything beyond trivial 
> one-tweak patches, by the way — I might not do this for a trivial source fix.
> 
> 
> Set up your local ports repository like you have, copy the current portfile 
> directory into it, etc.
> 
> Go to the port’s directory in the new repo, and 
> 
> sudo port -v build
> 
> when it errors, open a new terminal window, navigate to the same directory 
> you’re in now, and then
> 
> cd work
> sudo chmod -R a+rw .

This seems to go to the heart of the matter, so to speak.

> cd into the source directory, whatever it’s called, then set it up as a 
> temporary git repo:
> 
> git init
> git add .
> git commit -m “init” > /dev/null

And I have git to fall back on if there is an editing glitch or if I wish to do 
multiple fixes to my source.

> now you’re ready to do your work.
> 
> edit your source files as needed.
> 
> 
> You now have two terminal windows open. One is the port directory, one is the 
> source directory.
> 
> In the port directory, try your build again:
> 
> sudo port -v build
> 
> if you get errors, in your source directory, edit the files, then rebuild 
> again. Keep going until you get it to build.
> 
> Now you have changes in your new source git tree to save, so save those into 
> a diff file that you can use later:
> 
> git diff —no-prefix > ~/patches-for-my-fixed-port.diff
> 
> then see if your port will destroot, and then install.
> 
> sudo port -v destroot
> 
> sudo port -v -k install
> 
> (note the -k — that keeps it from blowing out your source directory if it 
> succeeds).

The above all worked very well, but only once… :-(

If I test the app I have installed and find there is still some problem, I need 
to edit the source and go back to the build step. But “build” just says "--->  
Computing dependencies for kpat”  and exits, even if I use “sudo port -f 
build”. It does not see that the source has changed.

I’m looking for something with an effect like “make” or “cmake", which senses 
that something has changed and starts a new build. That’s why I was having to 
keep changing the name of my patch-file before. I then had to edit the portfile 
and re-run portindex.

I also tried “sudo port clean”, but that wiped my source files as well as the 
build-files… :-D

Using “sudo port -k clean” also wipes the source files. Using “rm -rf 
work/build” sent the "build” command back to “Computing dependencies" and 
exiting, but the source files were still down in “work” and included an edit I 
had done before deleting “work/build/“.

Maybe there is some key file in work/build/ that I can delete or edit or 
execute, to trigger a new build with the latest source-code edits.

KPat is based on building with “cmake” to generate a Makefile and then “make” 
to do the build. Back in the day I would run CMake once and then keep running a 
make-test-edit cycle to do KDE development work.

Cheers,
Ian W.

> If all is well, you’re close to done. from your port directory
> 
> sudo port clean
> sudo port uninstall THEPORT
> 
> cd files
> mv  ~/patches-for-my-fixed-port.diff .
> cd ..
> bbedit Portfile
> 
> add your new patch
> 
> patchfiles-append  patches-for-my-fixed-port.diff
> 
> 
> and then try your build — hopefully it goes right through to installing, and 
> all your patches worked.
> 
> You’re done. Open your PR, have a latte, wait for someone to tell you how 
> wonderful you are (yeah, right!).
> 
> Ken

Fixing source-code bugs using MacPorts facilities.

[Ian Wadham]

Hi guys,

I have just been fixing a bug in the code for KPat, the KDE 4 Patience 
(Solitaire) game, using MacPorts facilities to submit, compile, build and 
install patches, including source code for fixing and testing bugs. I have 
followed the guidance in Chapter 4 of the MacPorts Guide 
https://guide.macports.org/chunked/development.html and especially sections 4.5 
Patch Files and 4.6 Local Portfile Repositories.

This has worked very well and I have had a patch committed upstream to the kpat 
master, but I am sure my workflow has been sub-optimal and I would like some 
suggestions for improving it before continuing on and fixing other bugs. The 
overall approach is workable because, although KDE Games is based on KDE 4 in 
MacPorts and the central KDE repositories are now about 5 years further on, the 
code I am interested in fixing is “game engine” code and has changed very 
little over that time period.

Following the Guide, I have set up the following “local port” data structure:

/kdedev/ports/
PortIndex
kde/
kpat/
portfile (editable)
files/
source code a.cpp (editable)
source code a.cpp.orig (read-only)
patch file patch-aN.cpp
patch file patch-bM.cpp
source code sub-directory patsolve/ (mirroring the source code 
structure)
source code b.cpp (editable, known as patsolve/b.cpp in 
patch files)
source code b.cpp.orig (read-only, known as 
patsolve/b.cpp.orig in patch files)

N and M are sequence numbers, which I bump every time I edit a.cpp or b.cpp and 
create a new version of the patch.

In MacPorts KPat is at version kpat @4.14.3_3. I began by bumping the revision 
line in my local portfile from 3 to 4. Then I uninstalled kpat and re-installed 
it using port -sk to get and keep the source. Then I copied the source code 
files kpat/a.cpp and patsolve/b.cpp, twice each, to create local files a.cpp, 
a.cpp.orig, patsolve/b.cpp and patsolve/b.cpp.orig.

My workflow was basically edit, patch, build, test, as follows:

Edit a source file
Generate a new patch file with a new number N or M
Edit kpat/portfile to record the new N or M in the patch-file name
Run portindex in directory /kdedev/ports
Change to /kdedev/ports/kde/kpat
Run sudo port uninstall kpat
Run sudo -sk install kpat
If any compile or link errors, go back to the edit step
Test kpat, either by running it from the dock or from the command line

To run from the command line and get stderr output, I would do cd . in 
directory /Applications/MacPorts/KDE4/kpat.app/Contents/MacOS to make the kpat 
executable visible in the Term window I dedicated to testing.

I know MacPorts developers have smarter ways of doing all this, so I hope 
someone can help.

Cheers,
Ian W.

P.S. My patches should be of value in fixing bugs in the MacPorts’ KDE 4 
version of KPat, which is no longer supported upstream.

Re: Libkdegames in Mojave (was Re: Jigsaw puzzles)

[Ian Wadham]

Hi Nicolas, Lenore and Franco,

Thank you very much for fixing this so promptly, Nicolas. I hope you will enjoy 
some jigsaw puzzling now, Lenore.

Here is a link to some brief descriptions of the KDE Games. The names may be 
unfamiliar, but many of the games will be recognised as old favourites.

https://kde.org/applications/games/

Cheers, Ian Wadham.

> On 17 Apr 2020, at 6:17 am, Lenore Horner  wrote:
> 
> Worked splendidly. Thanks!!
> 
>> On Apr 16, 2020, at 04:19, Nicolas Pavillon  wrote:
>> 
>> Hi, 
>> 
>> Sorry for missing that thread.
>> 
>>> See Comments #13 and after on Ticket #57294. 
>>> https://trac.macports.org/ticket/57294
>> 
>> I committed today a change in the kde4 Portgroup that should ideally fix the 
>> issue by enabling the compiler to properly find the OpenAL framework. Please 
>> reopen the ticket if there are still issues. 
>> 
>> Best,
>> 
>> Nicolas
>> 
>>> On Apr 13, 2020, at 12:13, Ian Wadham  wrote:
>>> 
>>> Hi Lenore and Franco,
>>> 
>>>> On 13 Apr 2020, at 12:58 pm, Ian Wadham  wrote:
>>> ……...
>>>> 
>>>> I believe Apple OSX uses OpenAL for its own sounds, which I daresay are 
>>>> still working on Mojave and Catalina, so Apple must have some new way of 
>>>> linking the OpenAL package into apps and other programs.
>>>> 
>>>> I will see if I can escalate this problem via Ticket #57294 or the 
>>>> MacPorts Developers’ list, but I have been out of touch with both for a 
>>>> long time.
>>> 
>>> Hmmm… It looks as if the experts are already onto it. See Comments #13 and 
>>> after on Ticket #57294. https://trac.macports.org/ticket/57294
>>> 
>>> Cheers, Ian W.
>>> 
>> 
> 

Re: Libkdegames in Mojave (was Re: Jigsaw puzzles)

[Ian Wadham]

Hi Lenore and Franco,

> On 13 Apr 2020, at 12:58 pm, Ian Wadham  wrote:
……...
> 
> I believe Apple OSX uses OpenAL for its own sounds, which I daresay are still 
> working on Mojave and Catalina, so Apple must have some new way of linking 
> the OpenAL package into apps and other programs.
> 
> I will see if I can escalate this problem via Ticket #57294 or the MacPorts 
> Developers’ list, but I have been out of touch with both for a long time.

Hmmm… It looks as if the experts are already onto it. See Comments #13 and 
after on Ticket #57294. https://trac.macports.org/ticket/57294

Cheers, Ian W.

Re: Libkdegames in Mojave (was Re: Jigsaw puzzles)

[Ian Wadham]

Hi Lenore and Franco,

> On 13 Apr 2020, at 5:18 am, Lenore Horner  wrote:
> 
> Ian, 
> Thanks for the help.  Results below.
> 
>> On Apr 12, 2020, at 01:39, Ian Wadham  wrote:
>> 
>> Hi Lenore,
>> 
>> Can you just try something for me on your Mojave system?
>> 
>> In a Terminal window type the command:
>> 
>>ll /System/Library/Frameworks/OpenAL.framework/Versions

> ls -l /System/Library/Frameworks/OpenAL.framework/Versions
> total 0
> drwxr-xr-x  5 root  wheel  160 Jul 29  2019 A
> lrwxr-xr-x  1 root  wheel1 Aug 19  2019 Current -> A
> 
> That doesn’t look different here.

That’s odd, I was expecting a B version for whatever Apple OSX is doing now in 
OpenAL.framework in Mojave, with the A version left as it was.

>> The command is said as “ell ell”, short for “long list”. On my system (High 
>> Sierra) I get output:
>> 
>>drwxr-xr-x  8 root  wheel  256  5 Apr 18:50 A/
>>lrwxr-xr-x  1 root  wheel1 19 Nov  2017 Current@ -> A
>> 
>> My guess is that, on Mojave, there will be an extra line, listing directory 
>> B/, and Current will point to B.
>> 
>> Please also try the command:
>> 
>>ls /System/Library/Frameworks/OpenAL.framework/Versions/Current/Headers
>> 
>> I get output:
>> 
>>MacOSX_OALExtensions.h  al.h
>>OpenAL.halc.h
>> 
>> meaning that the file “al.h” is there to be found.
> ls /System/Library/Frameworks/OpenAL.framework/Versions/Current/Headers
> ls: /System/Library/Frameworks/OpenAL.framework/Versions/Current/Headers: No 
> such file or directory
> 
> Looks like your bet is right.

Not so, I was expecting there to be at least one header, such as OpenAL.h, 
which incorporates al.h and alc.h (both are referenced by libkdegames code).

Instead we have no headers at all, not even a Headers directory. Weird…

I believe Apple OSX uses OpenAL for its own sounds, which I daresay are still 
working on Mojave and Catalina, so Apple must have some new way of linking the 
OpenAL package into apps and other programs.

I will see if I can escalate this problem via Ticket #57294 or the MacPorts 
Developers’ list, but I have been out of touch with both for a long time.

Cheers, Ian W.

>> What output do you get? My guess is that “al.h” will not be there on your 
>> Mojave system.
>> 
>> Cheers, Ian W.
>> 
>>> On 12 Apr 2020, at 1:53 pm, Ian Wadham  wrote:
>>> 
>>> Hi Lenore,
>>> 
>>>> On 12 Apr 2020, at 1:53 am, Lenore Horner  
>>>> wrote:
>>>> 
>>>> Ian, 
>>>> Thanks for a really nice suggestion.
>>> 
>>> Thank you for your kind words, Lenore.
>>> 
>>>> Sadly, libkdegames has had a failure on Mojave for the last 18 months.
>>> 
>>> I am really sorry to hear that. There are so many games in the KDE Games 
>>> collection that would be good for passing time during “lockdown”, not just 
>>> Palapeli.
>>> 
>>> I have had a look at MacPorts Ticket #57294 and especially at your comment 
>>> 12 and attachment.
>>> 
>>> It is certainly odd that KDE’s CMake processing reports, from lines 4163 to 
>>> 4173, that it has found the OpenAL and SndFile libraries and include files 
>>> - and where it has found them, see lines 4166 and 4167 - but then the build 
>>> crashes with
>>> 
>>>“…/libkdegames-4.14.3/audio/kgopenalruntime_p.h:25:10: fatal error: 
>>> 'al.h' file not found” in lines 4387 to 4391 inclusive.
>>> 
>>> Unfortunately I only have High Sierra installed (1 OSX release before 
>>> Mojave) and the last time I built KDE Games from MacPorts was November 
>>> 2017. However I will see if I can recall how the KDE Games builds work and 
>>> if I can get up-to-date with MacPorts, selfupdates and upgrades. I must 
>>> confess I am hopelessly behind with MacPorts maintenance (hell, I’m 82 
>>> now), but I did have some experience introducing the use of OpenAL into KDE 
>>> Games several years ago. I won’t be moving to Mojave any time soon, though.
>>> 
>>> Cheers, Ian W.
>>> 
>>>> There’s a purported solution followed by a comment that it’s not the right 
>>>> way to do things which leaves me debating whether to try a “not right way” 
>>>> solution that is reported to work but will maybe cause strangeness down 
>>>> the road for things that are more critical than a game.
>>>> Lenore
>>>> 
>>>>> On Mar 29, 2020, at 20:03, Ian Wadham  wrote:
>>>>> 
>>>>> If you like jigsaw puzzles and are isolated or stuck at home due to 
>>>>> coronavirus and looking for things to do, try the Palapeli port, which is 
>>>>> part of KDE Games 4.
>>>>> 
>>>>> …….
>>>>> Enjoy,
>>>>> Ian Wadham.

Re: Libkdegames in Mojave (was Re: Jigsaw puzzles)

[Ian Wadham]

Hi Lenore,

Can you just try something for me on your Mojave system?

In a Terminal window type the command:

ll /System/Library/Frameworks/OpenAL.framework/Versions

The command is said as “ell ell”, short for “long list”. On my system (High 
Sierra) I get output:

drwxr-xr-x  8 root  wheel  256  5 Apr 18:50 A/
lrwxr-xr-x  1 root  wheel1 19 Nov  2017 Current@ -> A

My guess is that, on Mojave, there will be an extra line, listing directory B/, 
and Current will point to B.

Please also try the command:

ls /System/Library/Frameworks/OpenAL.framework/Versions/Current/Headers

I get output:

MacOSX_OALExtensions.h  al.h
OpenAL.halc.h

meaning that the file “al.h” is there to be found.

What output do you get? My guess is that “al.h” will not be there on your 
Mojave system.

Cheers, Ian W.

> On 12 Apr 2020, at 1:53 pm, Ian Wadham  wrote:
> 
> Hi Lenore,
> 
>> On 12 Apr 2020, at 1:53 am, Lenore Horner  wrote:
>> 
>> Ian, 
>> Thanks for a really nice suggestion.
> 
> Thank you for your kind words, Lenore.
> 
>> Sadly, libkdegames has had a failure on Mojave for the last 18 months.
> 
> I am really sorry to hear that. There are so many games in the KDE Games 
> collection that would be good for passing time during “lockdown”, not just 
> Palapeli.
> 
> I have had a look at MacPorts Ticket #57294 and especially at your comment 12 
> and attachment.
> 
> It is certainly odd that KDE’s CMake processing reports, from lines 4163 to 
> 4173, that it has found the OpenAL and SndFile libraries and include files - 
> and where it has found them, see lines 4166 and 4167 - but then the build 
> crashes with
> 
> “…/libkdegames-4.14.3/audio/kgopenalruntime_p.h:25:10: fatal error: 
> 'al.h' file not found” in lines 4387 to 4391 inclusive.
> 
> Unfortunately I only have High Sierra installed (1 OSX release before Mojave) 
> and the last time I built KDE Games from MacPorts was November 2017. However 
> I will see if I can recall how the KDE Games builds work and if I can get 
> up-to-date with MacPorts, selfupdates and upgrades. I must confess I am 
> hopelessly behind with MacPorts maintenance (hell, I’m 82 now), but I did 
> have some experience introducing the use of OpenAL into KDE Games several 
> years ago. I won’t be moving to Mojave any time soon, though.
> 
> Cheers, Ian W.
> 
>> There’s a purported solution followed by a comment that it’s not the right 
>> way to do things which leaves me debating whether to try a “not right way” 
>> solution that is reported to work but will maybe cause strangeness down the 
>> road for things that are more critical than a game.
>> Lenore
>> 
>>> On Mar 29, 2020, at 20:03, Ian Wadham  wrote:
>>> 
>>> If you like jigsaw puzzles and are isolated or stuck at home due to 
>>> coronavirus and looking for things to do, try the Palapeli port, which is 
>>> part of KDE Games 4.
>>> 
>>> …….
>>> Enjoy,
>>> Ian Wadham.
>> 
> 

Libkdegames in Mojave (was Re: Jigsaw puzzles)

[Ian Wadham]

Hi Lenore,

> On 12 Apr 2020, at 1:53 am, Lenore Horner  wrote:
> 
> Ian, 
> Thanks for a really nice suggestion.

Thank you for your kind words, Lenore.

> Sadly, libkdegames has had a failure on Mojave for the last 18 months.

I am really sorry to hear that. There are so many games in the KDE Games 
collection that would be good for passing time during “lockdown”, not just 
Palapeli.

I have had a look at MacPorts Ticket #57294 and especially at your comment 12 
and attachment.

It is certainly odd that KDE’s CMake processing reports, from lines 4163 to 
4173, that it has found the OpenAL and SndFile libraries and include files - 
and where it has found them, see lines 4166 and 4167 - but then the build 
crashes with

 “…/libkdegames-4.14.3/audio/kgopenalruntime_p.h:25:10: fatal error: 'al.h' 
file not found” in lines 4387 to 4391 inclusive.

Unfortunately I only have High Sierra installed (1 OSX release before Mojave) 
and the last time I built KDE Games from MacPorts was November 2017. However I 
will see if I can recall how the KDE Games builds work and if I can get 
up-to-date with MacPorts, selfupdates and upgrades. I must confess I am 
hopelessly behind with MacPorts maintenance (hell, I’m 82 now), but I did have 
some experience introducing the use of OpenAL into KDE Games several years ago. 
I won’t be moving to Mojave any time soon, though.

Cheers, Ian W.

> There’s a purported solution followed by a comment that it’s not the right 
> way to do things which leaves me debating whether to try a “not right way” 
> solution that is reported to work but will maybe cause strangeness down the 
> road for things that are more critical than a game.
> Lenore
> 
>> On Mar 29, 2020, at 20:03, Ian Wadham  wrote:
>> 
>> If you like jigsaw puzzles and are isolated or stuck at home due to 
>> coronavirus and looking for things to do, try the Palapeli port, which is 
>> part of KDE Games 4.
>> 
>> …….
>> Enjoy,
>> Ian Wadham.
> 

Jigsaw puzzles

[Ian Wadham]

If you like jigsaw puzzles and are isolated or stuck at home due to coronavirus 
and looking for things to do, try the Palapeli port, which is part of KDE Games 
4.

Advantages are:

- You can cut your own puzzles from your own photos, etc.
- You can choose the number of pieces and the general shape, using any of 
several “slicer” modules.
- When playing, the game saves its state to disk every two seconds.
- It can handle puzzles up to 10,000 pieces in size, providing “holder” windows 
for subsets of pieces, such as Sky, Edges, etc.
- The manual is comprehensive and is online at 
https://docs.kde.org/trunk5/en/kdegames/palapeli/index.html or google kde docs 
palapeli.
- An optional Preview window lets you see all or part of the completed puzzle.
- The game is in good working order, except for occasional crashes with minor 
impact (see below).
- You get a starter library of five easy puzzles and can add your own puzzles 
to it.

Disadvantages are:

- Palapeli takes a while to install under MacPorts, because it has a huge chain 
of dependencies via qt4-mac and kdelibs4, but you can break up the load by 
installing those two ports first from the binaries.
- Pieces are not rotated when the puzzle is shuffled.
- The functionality of the game has not changed for a few years: I was the last 
maintainer, but am retired from FOSS development now.
- Crashes can occur when you move and join pieces rapidly: I was never able to 
find why, but the autosave feature (see above) ensures that you do not lose 
hours of work.
- If you have a Linux system, Palapeli is available in a maintained KF5 
version, but I don’t think there are many bug fixes or new features.

“Palapeli" is a German word with a meaning something like “pell-mell” in 
English.

Enjoy,
Ian Wadham.

Re: Qt4/KDE4 software under 10.14

[Ian Wadham]

Hi René,

Long time no see.

> On 11 Oct 2018, at 5:10 am, René J.V. Bertin  wrote:
> I'm trying to figure out why port:kde4-workspace fails to build on 10.14, 
> with linker errors that suggest that the system clang has a subtle new and 
> incompatible symbol visibility policy. 
> (https://trac.macports.org/ticket/57332).
> 
> Are there known issues with Qt4 and/or KDE4 software on Apple's latest and 
> greatest (desert environment O:^))?
> 
> R.

I am on 10.13.6 High Sierra and have no plans to move to Mojave. However, I 
have Xcode !0.0 (10A255) and several recent updates to Command Line Tools which 
were hitting my system almost daily just before the Mojave release date (c. 24 
Sept?). I believe those versions of Xcode and CLT are “Mojave ready” and may 
have some of the problems you and others are experiencing in Mojave.

At the time (3rd week in September) I was attempting to upgrade my former 
MacBook Pro (early 2011) from Lion to High Sierra in order to give it to my 
son. The word from Apple (then) was to first upgrade from Lion to El Capitan 
and then upgrade to High Sierra. There were numerous problems in this process, 
necessitating about 3 hours on the ‘phone to Apple Support, who were very 
helpful. I think the problems were mainly due to changes in security policies 
at the App Store and in Apple Accounts since Lion, but also the replacement of 
Apple app iPhoto by an iOS-like Photos app, which threw up some errors.

All that need not concern us here, but I did notice some graphics glitches and 
other weird happenings in the resultant High Sierra desktop, unrelated to KDE 
4. I wonder if there is some problem in Apple’s upgrade path from older systems 
to Xcode 10.0 and High Sierra or Mojave… I decided to stop struggling with the 
upgraded system.

I saved offline all the files I wanted to keep, then followed Apple’s 
recommended procedure for handing over ownership of an old machine (Apple’s 
only supported procedure for that?) — i.e. I wiped and re-formatted my old 
machine’s hard disk and installed High Sierra “from scratch”, using my son’s 
Apple Account and login ID. The resulting system worked fine and my son is 
delighted with it.

Re KDE 4, I believe the source code used in MacPorts is from the KDE 4.14.3 
release in November 2014, the last “official" release of KDE 4 libraries and 
apps. However, there were some releases of KDE 4 apps (and maybe some 
libraries) in the “Applications” series of releases. See 
https://community.kde.org/Schedules.

At some point, when the porting of KDE apps to KF5 was complete, the 
“Applications” releases stopped accepting KDE 4 code, but I forget exactly when 
that was. Certainly I was able to release new features in some of my KDE Games 
in 2015, using KDE 4 libraries (notably the Palapeli and KSudoku games). Others 
have helpfully ported those games to KF5, but I myself have never been able to 
get KF5 and Qt5 built and working on my Apple machine.

Re your build problem, I now find I cannot build KDE 4 Palapeli code with High 
Sierra and Xcode 10.0 and its CLT, using my local source repositories, which 
contain updates that are in the KDE central origin/master but after KDE 4.14.3. 
There are three classes of problem: one fatal and two in the warnings category.

One of the warnings is a whole lot of messages of the form:

ld: warning: text-based stub file 
/System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices.tbd
 and library file  

/System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices
 are out of sync. Falling back to library file for linking.

I googled this and apparently a *.tbd file is a cache for symbols in a 
corresponding library and gets out of synch with its library. The cache is 
supposed to speed up Xcode operations. Trivial as the problem may be, it 
suggests that there may be other problems in Apple’s migration paths from one 
OS X version to another.

The second type of warning is to do with KDE code that uses the words “struct” 
and “class” interchangeably for the same body of data and methods. Clang has 
been complaining about this for several years, but it has never caused build 
problems. Example:

/kdedev/games/palapeli/libpala/slicerproperty.cpp:25:1: warning: 'Private' 
defined as
  a struct here but previously declared as a class [-Wmismatched-tags]
struct Pala::SlicerProperty::Private
^
/kdedev/games/palapeli/libpala/slicerproperty.h:86:4: note: did you mean 
struct here?
class Private;
^
struct

There are loads of warnings like the above in the Palapeli compile.

Finally the build of Palapeli fails because of undefined symbols. Curiously, 
the missing symbols seem to relate to the areas of code where the (non-fatal) 
struct/class ambiguities occur. Is this a pattern or a coincidence? I have not 
tried it with MacPorts’ snapshot of 

Re: User information about macOS Mojave

[Ian Wadham]

> On 20 Sep 2018, at 6:04 pm, Chris Jones  wrote:
> On 20/09/18 06:35, Ian Wadham wrote:
>>> On 20 Sep 2018, at 3:54 am, Ryan Schmidt  wrote:
>>> 
>>> On Sep 19, 2018, at 11:54, Richard L. Hamilton wrote:
>>> 
>>>> So I think that the 10.13 SDK on Mojave, assuming one can still build 
>>>> against it there, may well be a short-term answer.
>>> 
>>> Mojave requires Xcode 10 which contains only the 10.14 SDK.
>>> 
>>> MacPorts doesn't have any particular support at this time for accessing 
>>> alternative SDKs that the user might have placed in other locations.
>> I am on High Sierra 10.13.6, but the App Store app told me to upgrade to 
>> Xcode 10 and command line tools 10 (on 19 Sept 2018), so I did.
>> Now I am getting weird messages from ld when compiling and building some of 
>> my own C++ code which is based on KDE libraries obtained from Macports. Here 
>> is one example:
>> ld: warning: text-based stub file 
>> /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices.tbd
>>  and library file 
>> /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices
>>  are out of sync. Falling back to library file for linking.
>> There are other similar ones relating to CoreGraphics.framework, 
>> CoreText.framework, ImageIO.framework, CoreServices.framework and 
>> CFNetwork.framework.
>> Also I am getting loads of compiler warning messages about mismatched 
>> ‘struct’ and ‘class’ keyword usages and loads of undefined ld symbols re the 
>> classes and methods affected. So the whole build fails.
>> I had not edited, compiled or built that code since a few months ago.
>> Have I gone an Xcode version or a compiler version too far? If so, what 
>> should I do?
> 
> I've updated and not had any such problems.
> 
> Have you installed / updated the command line tools for Xcode 10 ? They 
> should have come as an update on their own. Does clang give the ame versions 
> as below for you ?

Thanks very much  for your reply, Chris.

I have Xcode and command line tools, both at v 10.0, updated on Wed 19 Sept 
2018.

> > clang --version
> Apple LLVM version 10.0.0 (clang-1000.11.45.2)
> Target: x86_64-apple-darwin17.7.0
> Thread model: posix
> InstalledDir: 
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I get exactly the same output here for ‘clang —version’, also for 
‘/usr/bin/clang’, which is what the CMake command in my build-script is using.

I shall dig further when I have some time.

Thanks again, Ian W.

>>> I worked on a port to standardize a way to provide other SDK versions, but 
>>> I have not published it yet. MacPorts base changes would also be required 
>>> to make it easy for ports to request SDKs that didn't come from the primary 
>>> Xcode installation.
>>> 
>>> 
>>>> But IMO, this is still a good excuse to at least get STARTED on pushing 
>>>> everything toward x86_64, even if workarounds are still mostly possible; 
>>>> because in the next OS version, i386 will likely be gone or severely 
>>>> crippled.
>>> 
>>> Apple has announced that macOS 10.15 will remove all 32-bit support.
>>> 
>>> 

Re: User information about macOS Mojave

[Ian Wadham]

> On 20 Sep 2018, at 3:54 am, Ryan Schmidt  wrote:
> 
> On Sep 19, 2018, at 11:54, Richard L. Hamilton wrote:
> 
>> So I think that the 10.13 SDK on Mojave, assuming one can still build 
>> against it there, may well be a short-term answer.
> 
> Mojave requires Xcode 10 which contains only the 10.14 SDK.
> 
> MacPorts doesn't have any particular support at this time for accessing 
> alternative SDKs that the user might have placed in other locations.

I am on High Sierra 10.13.6, but the App Store app told me to upgrade to Xcode 
10 and command line tools 10 (on 19 Sept 2018), so I did.

Now I am getting weird messages from ld when compiling and building some of my 
own C++ code which is based on KDE libraries obtained from Macports. Here is 
one example:

ld: warning: text-based stub file 
/System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices.tbd
 and library file 
/System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices
 are out of sync. Falling back to library file for linking.

There are other similar ones relating to CoreGraphics.framework, 
CoreText.framework, ImageIO.framework, CoreServices.framework and 
CFNetwork.framework.

Also I am getting loads of compiler warning messages about mismatched ‘struct’ 
and ‘class’ keyword usages and loads of undefined ld symbols re the classes and 
methods affected. So the whole build fails.

I had not edited, compiled or built that code since a few months ago.

Have I gone an Xcode version or a compiler version too far? If so, what should 
I do?

Cheers, Ian W.

> I worked on a port to standardize a way to provide other SDK versions, but I 
> have not published it yet. MacPorts base changes would also be required to 
> make it easy for ports to request SDKs that didn't come from the primary 
> Xcode installation.
> 
> 
>> But IMO, this is still a good excuse to at least get STARTED on pushing 
>> everything toward x86_64, even if workarounds are still mostly possible; 
>> because in the next OS version, i386 will likely be gone or severely 
>> crippled.
> 
> Apple has announced that macOS 10.15 will remove all 32-bit support.
> 
> 

Re: kde help center -- "The file or folder help:/XYZ does not exist

[Ian Wadham]

Hi Ken,

> On 12 May 2018, at 12:28 am, Ken Cunningham  
> wrote:
> 
> More or less total KDE newbie...
> 
> Almost every entry in the kde help center fails due to an error like the 
> above.
> 
> Is this something I have forgotten to install, or is it just non-functional 
> on MacPorts installs at present?

I think KDE 4 apps are still installed without docs in MacPorts because of an 
intermittent
build crash that could never get diagnosed and fixed.

You can see KDE 5 user guides at docs.kde.org. These are mostly much the same 
as the
KDE 4 docs or only slightly advanced. Otherwise you can build with +docs in 
MacPorts
(which is from source rather than a binary package), but it takes a long time 
and drags in
doco for all the many dependencies of KDE 4 apps.

> Ken

Cheers, Ian W.

Re: What happened to qt4-mac's qmake utility (re High Sierra v. Lion)?

[Ian Wadham]

> On 23 Nov 2017, at 4:38 pm, Nicolas Pavillon <pavillon.nico...@gmail.com> 
> wrote:
> I don’t think the change in prefix is platform dependent. This happened quite 
> some time ago to allow co-installation of both qt5 and qt4-mac (see 
> https://trac.macports.org/changeset/140960). As far as ports are concerned, 
> their compilation should have been fixed also quite some time ago.
> If you need to find specific qt4 components in your own codes, I imagine that 
> setting QTDIR should be enough (just a wild guess), which
> is now set to ${prefix}/libexec/qt4.

Thanks, Nicolas, I might try that. Nice to see you are still around... :-)
Cheers, Ian W.

>> On Nov23, 2017, at 12:36, Ian Wadham <iandw...@gmail.com> wrote:
>> 
>> I have been setting up a new MacBook Pro 13-inch with High Sierra.
>> Macports is building and running fine with qt4-mac, kdegames4 and kmymoney4
>> requested and a long list of dependencies installed.
>> 
>> Now I am trying to resurrect some of the KDE 4 source-code and applications
>> I used to work on when I was a KDE developer. I brought across a bunch of 
>> source
>> from my old MacBook Pro (2011 vintage and using Lion). But when I went to 
>> build
>> it CMake failed during its checks of the software and hardware environment, 
>> which
>> it does before starting to generate a makefile and build.
>> 
>> Specifically, CMake could not find qmake, Qt’s utility for generating 
>> builds. Using
>> “port contents” I found that qt4-mac @4.8.7_5 has qmake installed at 
>> /opt/local/bin
>> on Lion, but on High Sierra it is at /opt/local/libexec/qt4/bin, which is 
>> not in my $PATH.
>> 
>> So why has qmake moved?
>> 
>> And what should I add to my $PATH, /opt/local/libexec/qt4/bin? Or would 
>> /opt/local/libexec
>> be enough (and more general)? Or perhaps CMake needs some option?
>> 
>> All the best, Ian W.
>> 
> 

Re: What happened to qt4-mac's qmake utility (re High Sierra v. Lion)?

[Ian Wadham]

> On 23 Nov 2017, at 4:38 pm, Ryan Schmidt <ryandes...@macports.org> wrote:
> 
> 
> On Nov 22, 2017, at 21:36, Ian Wadham wrote:
> 
>> I have been setting up a new MacBook Pro 13-inch with High Sierra.
>> Macports is building and running fine with qt4-mac, kdegames4 and kmymoney4
>> requested and a long list of dependencies installed.
>> 
>> Now I am trying to resurrect some of the KDE 4 source-code and applications
>> I used to work on when I was a KDE developer. I brought across a bunch of 
>> source
>> from my old MacBook Pro (2011 vintage and using Lion). But when I went to 
>> build
>> it CMake failed during its checks of the software and hardware environment, 
>> which
>> it does before starting to generate a makefile and build.
>> 
>> Specifically, CMake could not find qmake, Qt’s utility for generating 
>> builds. Using
>> “port contents” I found that qt4-mac @4.8.7_5 has qmake installed at 
>> /opt/local/bin
>> on Lion, but on High Sierra it is at /opt/local/libexec/qt4/bin, which is 
>> not in my $PATH.
>> 
>> So why has qmake moved?
>> 
>> And what should I add to my $PATH, /opt/local/libexec/qt4/bin? Or would 
>> /opt/local/libexec
>> be enough (and more general)? Or perhaps CMake needs some option?
> 
> qmake and other qt programs and files moved so that the qt4-mac and qt5 ports 
> could be installed simultaneously. Ports using qt are meant to use the 
> various qt portgroups, which set variables that the port can use to access 
> the locations of those files. If you're trying to build your own software 
> outside of MacPorts but using MacPorts qt, I guess you'll have to put the 
> right path into your $PATH. The right path is the one that contains the 
> binary you want to use. I don't know if modifying the $PATH is enough for 
> cmake to be able to find things.

Good answer. Thanks, Ryan. Putting Qt’s libexec on the $PATH does placate CMake 
and the build then proceeds normally.
Cheers, Ian W.

What happened to qt4-mac's qmake utility (re High Sierra v. Lion)?

[Ian Wadham]

I have been setting up a new MacBook Pro 13-inch with High Sierra.
Macports is building and running fine with qt4-mac, kdegames4 and kmymoney4
requested and a long list of dependencies installed.

Now I am trying to resurrect some of the KDE 4 source-code and applications
I used to work on when I was a KDE developer. I brought across a bunch of source
from my old MacBook Pro (2011 vintage and using Lion). But when I went to build
it CMake failed during its checks of the software and hardware environment, 
which
it does before starting to generate a makefile and build.

Specifically, CMake could not find qmake, Qt’s utility for generating builds. 
Using
“port contents” I found that qt4-mac @4.8.7_5 has qmake installed at 
/opt/local/bin
on Lion, but on High Sierra it is at /opt/local/libexec/qt4/bin, which is not 
in my $PATH.

So why has qmake moved?

And what should I add to my $PATH, /opt/local/libexec/qt4/bin? Or would 
/opt/local/libexec
be enough (and more general)? Or perhaps CMake needs some option?

All the best, Ian W.

Re: kmymoney4 failure on Sierra (was In a mess with libc++ libstdc++ and OSX 10.7.5 Lion)

[Ian Wadham]

Hi Rainer and thanks,

Can someone please nudge Marko Kaening, the maintainer of the kmymoney4 port
re ticket https://trac.macports.org/ticket/54604 ?

That is why I was trying to register with GitHub, but the registration failed, 
so I could
not update Macports' trac myself.

At least 3 people have experienced the problem in 5 weeks and it is a 
showstopper for
anyone wishing to use KMyMoney 4 to do their finances on Sierra, but no action 
yet.

Cheers, Ian W.

On 17/09/2017, at 11:32 PM, Rainer Müller wrote:

> On 2017-09-17 05:16, Ian Wadham wrote:
>> I went through the procedure to register with GitHub, but I have not 
>> received a
>> confirmatory email from there, despite checking the email address I entered 
>> and
>> requesting a resend many times.  I also checked spam boxes and gmail website.
> 
> Sorry to hear that. Please contact GitHub support to get assistance with
> setting up your account:
> 
> https://github.com/contact
> 
> Rainer

Re: In a mess with libc++ libstdc++ and OSX 10.7.5 Lion

[Ian Wadham]

Thanks, Ken.

On 17/09/2017, at 1:59 PM, Ken Cunningham wrote:
> Ah, the unlucky 2%. 
> 
> C'est la vie.
> 
> Such problems are generally always fixable, the equation being time vs 
> benefit…

Versus, in my case, updating the books by hand.  It should only take a few 
days...
Luckily I have hard copy of reports from last year.  Maybe even my KMyMoney
data-file would be loadable into other software…  We'll see.

Cheers, Ian W.

> On 2017-09-16, at 8:38 PM, Ian Wadham wrote:
> 
>> Hi Ken,
>> 
>> On 14/09/2017, at 2:43 PM, Ken Cunningham wrote:
>>> Keeping a 10.7 machine going is always going to be more of a project than a 
>>> new machine, but not necessarily hopeless. Upgrading to a Sierra machine is 
>>> always the path of least resistance, if that is in your horizon. 
>>> Nonetheless, there is _usually_ a way to keep your 10.7 machine running 
>>> with _most_ open source software. No guarantees, though.
>>> 
>>> For the simplest fix that requires the least amount of locally-built 
>>> software and the least amount of time, do this:
>>> 
>>> when you see a port that tells you something like:
>>> 
>>> Error: akonadi does not support your selected MacPorts C++ runtime. libc++ 
>>> must be selected and C++-based ports built against it.
>>> 
>>> you can try the following:
>>> 
>>> edit `port file akonadi` in your favourite editor, like vi or bbedit. You 
>>> might need sudo.
>>> 
>>> change the following line, usually near the top:
>>> 
>>> PortGroup   cxx11   1.0 
>>> 
>>> to 
>>> 
>>> PortGroup   cxx11   1.1
>>> 
>>> and then hope the Gods are smiling on you. I would say there is about a 98% 
>>> chance it will "just work". If it does not work, then the next option is a 
>>> wholesale change to libc++, which I did in the end, and I think that works 
>>> the best. But there is currently no libc++ buildbot, so you'll have to 
>>> build *everything*. That will take several days (and is also not guaranteed 
>>> to work).
>> 
>> FWIW, that did not work for me.  It caused some new tools to be installed,
>> such as gcc6, after I had done "port clean akonadi" and "port install 
>> akonadi",
>> then this time the error message was:
>> 
>> :info:build Undefined symbols for architecture x86_64:
>> :info:build   "std::runtime_error::runtime_error(char const*)", referenced 
>> from:
>> :info:build   boost::function1<void, std::string 
>> const&>::operator()(std::string const&) const in 
>> libakonadi_shared.a(akapplication.cpp.o)
>> :info:build ld: symbol(s) not found for architecture x86_64
>> :info:build clang: error: linker command failed with exit code 1 (use -v to 
>> see invocation)
>> :info:build make[2]: *** [bin/akonadi_agent_server] Error 1
>> 
>> but I do not understand it, not being familiar with boost etc.
>> 
>> As you can see from another email, I am trying Sierra on a new machine,
>> and that has a problem, but I still have my old machine on 10.7 Lion.
>> 
>> Cheers, Ian W.
>> 
> 

Re: In a mess with libc++ libstdc++ and OSX 10.7.5 Lion

[Ian Wadham]

Hi Ken,

On 14/09/2017, at 2:43 PM, Ken Cunningham wrote:
> Keeping a 10.7 machine going is always going to be more of a project than a 
> new machine, but not necessarily hopeless. Upgrading to a Sierra machine is 
> always the path of least resistance, if that is in your horizon. Nonetheless, 
> there is _usually_ a way to keep your 10.7 machine running with _most_ open 
> source software. No guarantees, though.
> 
> For the simplest fix that requires the least amount of locally-built software 
> and the least amount of time, do this:
> 
> when you see a port that tells you something like:
> 
> Error: akonadi does not support your selected MacPorts C++ runtime. libc++ 
> must be selected and C++-based ports built against it.
> 
> you can try the following:
> 
> edit `port file akonadi` in your favourite editor, like vi or bbedit. You 
> might need sudo.
> 
> change the following line, usually near the top:
> 
> PortGroup   cxx11   1.0 
> 
> to 
> 
> PortGroup   cxx11   1.1
> 
> and then hope the Gods are smiling on you. I would say there is about a 98% 
> chance it will "just work". If it does not work, then the next option is a 
> wholesale change to libc++, which I did in the end, and I think that works 
> the best. But there is currently no libc++ buildbot, so you'll have to build 
> *everything*. That will take several days (and is also not guaranteed to 
> work).

FWIW, that did not work for me.  It caused some new tools to be installed,
such as gcc6, after I had done "port clean akonadi" and "port install akonadi",
then this time the error message was:

:info:build Undefined symbols for architecture x86_64:
:info:build   "std::runtime_error::runtime_error(char const*)", referenced from:
:info:build   boost::function1::operator()(std::string const&) const in 
libakonadi_shared.a(akapplication.cpp.o)
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
:info:build make[2]: *** [bin/akonadi_agent_server] Error 1

but I do not understand it, not being familiar with boost etc.

As you can see from another email, I am trying Sierra on a new machine,
and that has a problem, but I still have my old machine on 10.7 Lion.

Cheers, Ian W.

Re: In a mess with libc++ libstdc++ and OSX 10.7.5 Lion

[Ian Wadham]

Hi Chris,

On 14/09/2017, at 6:10 PM, Chris Jones wrote:
>> I understand what these messages mean and I have read the Macports Wiki pages
>> referred to, but I am uncertain what to do next.
>> 1. Do I need to do any cleanup of the failed run before doing anything else? 
>>  If so,
>>  what command(s) should I use?
>> 2. I had a local ports tree that I no longer use.  I have commented out the 
>> reference
>> to it in sources.conf but do I need to re-run portindex?  Or would that 
>> have been
>> taken care of when I ran "sudo port selfupdate"?  I have not found any 
>> way to
>> re-index and include just the standard ports.
>> 3. Can I revert to earlier versions of apps and libraries (which could at 
>> least be used
>> to keep my accountant happy)?  If so, what commands should I use?  There 
>> are
>> scores, maybe hundreds, of ports to be reactivated and there are 
>> probably lots
>> that are old but still active, because the upgrade run never got to them.
>> 4. If I stay with Lion, I understand that I have to uninstall everything, 
>> make some
>> adjustments to macports.conf and then re-build from source and continue 
>> to
>> do so into the future.
>> OTOH I could go down to the Apple shop and get them to upgrade me to 
>> Sierra
>> and then I could re-install MacPorts apps from binaries but I would also 
>> have to
>> upgrade other non-Apple software I depend on a lot every day, mainly 
>> Firefox
>> and LibreOffice.
>> Either approach could take days (elapsed) and many hours of computer 
>> time.
>> Which way would be best for me to go?
> 
> Go with 4. Update to Sierra, it will save you most trouble in the long run. 
> No need at all to go to a store to get it done though, just do it 
> yourself Download the updater from the App Store and follow the 
> instructions. Firefox and LibreOffice might also need updating, if you 
> haven't kept them up to date, but both will work fine in the newer OS.
> 
> cheers Chris

If I go to Sierra, will I lose the Apple apps in Lion that play (and burn)
DVDs?  I notice that new MacBook Pros with Sierra usually do not have
a CD/DVD drive…  Of course Sierra will still have iTunes, but will it
still play CDs?  I only ever use iTunes for that.

Cheers, Ian W.

In a mess with libc++ libstdc++ and OSX 10.7.5 Lion

[Ian Wadham]

I am in a right royal mess with some KDE 4 applications and libraries from 
MacPorts
on which I depend.  After a failed "sudo port upgrade outdated" run all my KDE 
4 apps
give OSX popup messages like "kmymoney cannot be opened because of a problem"
and they wil not start.  The most serious (for me) is KMyMoney, which holds all 
my
finances and investments, and it is time for me to do annual accounting and tax.

I am using OSX 10.7.5 Lion and MacPorts 2.4.1.

It was some time since I had done a port upgrade outdated, maybe a year or more.
However a "sudo port selfupdate" showed that I was already at macports 2.4.1.  
I then
ran and saved lists of requested and outdated ports and uninstalled a few ports 
I no
longer need.  Then I started "sudo port upgrade outdated".

The terminal output ended with multiple repetititions of:
Warning: reinplace /include/s@\(utils\.h\)@src/\1@g didn't change anything in 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_akonadi/akonadi/work/akonadi-1.13.1.20141210/server/tests/unittest/searchtest.cpp

Followed by:
--->  Configuring akonadi
Error: akonadi does not support your selected MacPorts C++ runtime. libc++ must 
be selected and C++-based ports built against it.
Error: Please follow the instructions on 
https://trac.macports.org/wiki/LibcxxOnOlderSystems.
Error: After adding the required options to macports.conf, reinstall all ports 
like you would when switching macOS versions.
Error: Follow step 3 on https://trac.macports.org/wiki/Migration in order to do 
this.
Error: Failed to configure akonadi: libstdc++ unsupported.
Error: See 
/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_akonadi/akonadi/main.log
 for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

I understand what these messages mean and I have read the Macports Wiki pages
referred to, but I am uncertain what to do next.

1. Do I need to do any cleanup of the failed run before doing anything else?  
If so,
 what command(s) should I use?

2. I had a local ports tree that I no longer use.  I have commented out the 
reference
to it in sources.conf but do I need to re-run portindex?  Or would that 
have been
taken care of when I ran "sudo port selfupdate"?  I have not found any way 
to
re-index and include just the standard ports.

3. Can I revert to earlier versions of apps and libraries (which could at least 
be used
to keep my accountant happy)?  If so, what commands should I use?  There are
scores, maybe hundreds, of ports to be reactivated and there are probably 
lots
that are old but still active, because the upgrade run never got to them.

4. If I stay with Lion, I understand that I have to uninstall everything, make 
some
adjustments to macports.conf and then re-build from source and continue to
do so into the future.

OTOH I could go down to the Apple shop and get them to upgrade me to Sierra
and then I could re-install MacPorts apps from binaries but I would also 
have to
upgrade other non-Apple software I depend on a lot every day, mainly Firefox
and LibreOffice.

Either approach could take days (elapsed) and many hours of computer time.
Which way would be best for me to go?

I used to be a KDE developer until about 2 years ago, so I am happy working with
commands and scripts, and I have saved lists of requested ports and of the new 
and
old versions of outdated ports.

Hope you can help,
Ian W.