Re: Why would Kreversi want a spell checker?
> 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
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
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
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
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
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
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
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
> 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
> 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?
> 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?
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
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?
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
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?
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
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
> 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.
> 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.
> 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.
> 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.
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.
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.
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)
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)
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)
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)
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)
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
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
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 cod
Re: User information about macOS Mojave
> 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
> 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
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)?
> On 23 Nov 2017, at 4:38 pm, Nicolas Pavillon
> 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 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)?
> On 23 Nov 2017, at 4:38 pm, Ryan Schmidt 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)?
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)
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
Hi db and guys, Good news! I have managed to revert to the previous working versions of all my ports, in effect reversing the effects of the failed "port upgrade outdated". On 17/09/2017, at 10:19 PM, db wrote: > On 17 Sep 2017, at 07:56, Ian Wadham wrote: >> 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. > > Did you try going back to a branch of MP that can actually build kmymoney4 in > your Lion system? > > # backup /opt/local/ and /Applications/MacPorts/ > sudo port uninstall installed > cd /opt/local/var/macports/sources/github.com/macports/macports-ports/ > # search a commit around the time you last modified your data file > git log | grep 'commit\|Date' > # or just try the first from 2016 > git checkout 1a4d3d46b6eb55dc007e4b909c04c078b7130f35 > sudo port install kmymoney4 > # if it doesn't work search for another commit and retry Thanks, but I did not try this. Instead I did something else. I remembered that, before the "port upgrade outdated" I had uninstalled all the inactive ports, quite by accident actually --- by not understanding the full implications of "port -u uninstall xxx", where xxx was a port I no longer required. Not only did it uninstall all active and inactive versions of xxx, but also it went on to uninstall ALL inactive ports… Anyway, this meant that I could undo the effects of the partial "port upgrade outdated" simply by: sudo port clean akonadi # Clean the port that failed to upgrade. sudo port activate inactive# Reinstate previous versions of ports that upgraded. And voila, all is as it was in my Lion machine. My financial records are accessible again… :-) In future, I think I will make a list of all active ports before using "port upgrade outdated", then I can use it to revert the upgrade should anything go wrong. Thanks very much for all your help, Cheers, Ian W.
Re: In a mess with libc++ libstdc++ and OSX 10.7.5 Lion
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> 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
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: kmymoney4 failure on Sierra (was In a mess with libc++ libstdc++ and OSX 10.7.5 Lion)
Thank you very much Mojca and Chris for all your advice. Thanks also to db and pagani laurent for passing on their experience re Sierra and use of TimeMachine with MacPorts. On 14/09/2017, at 6:34 PM, Mojca Miklavec wrote: > On 14 September 2017 at 10:10, Chris Jones wrote: >> >> Update to Sierra, After some thought I decided to throw money at the problem. I went and bought a new MacBook Pro 13" with Sierra. I have been drooling over the screen clarity on my son's machine for years… :-) But now there is a new problem. I installed Xcode, command-line options and MacPorts in the new machine. Otherwise it contains just what Apple delivered. Then I requested MacPorts to install qt4-mac and followed by kdegames4. That all went fine. Then I requested MacPorts to install kmymoney4 and that all went fine, including installing akonadi (which had given me problems on Lion on my old machine), BUT kmymoney4 itself failed to install… :-( The problem is exactly as in https://trac.macports.org/ticket/54604 but I have not been able to add a comment to the ticket. 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. I see that at least three people, including me, have had this problem in the last 5 weeks but there has been no action. It is a showstopper if you are relying on KMyMoney to help with your financial accounting. Could someone, maybe Ryan, give Marko a nudge. Cheers, Ian W. >> 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. > > Just to avoid any confusion from my long complex email: this *exactly* > is my opinion as well. > > Going back in time and activate ports that already worked for you > might be the fastest solution in the short run that could be done in > 15-60 minutes (if you know what you are doing) without taking other > risks of potentially hitting other issues on the new os. > > But once the super-hurry is over, going to Sierra would greatly > greatly reduce most of your headaches in the long run. The upgrade > should be pretty fast and painless anyway. > > Any OSes below 10.9 are a bit of a headache and besides of security > risks & lack of software it only makes sense to use them if you know > exactly what you are doing and if you can help yourself when you hit > problems. > > High Sierra is also on the way, but it will bring its own set of > headaches until the majority of ports are fixed, so probably not > suggested to install it yet if you cannot live with broken ports. > > Mojca >
Re: In a mess with libc++ libstdc++ and OSX 10.7.5 Lion
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.
Re: In a mess with libc++ libstdc++ and OSX 10.7.5 Lion
Hi everybody, Thank you so very much for all the helpful advice and suggestions. I live in Australia, so it is TV veg-out time and nearly bedtime. I will work through all your replies in detail in the morning. On 14/09/2017, at 7:57 PM, db wrote: > On 14 Sep 2017, at 06:30, Ian Wadham wrote: >> 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. > > In case you have Time Machine or a clone, just restore /opt/local/ and > /Applications/MacPorts/. Heh, heh! Someone else suggested that and it was also one of the first things I thought of. But guess what. I have TimeMachine, but my settings exclude backing up /opt/local and several other build/object-code areas, on the basis that they are large and the wherewithal to re-create them is easily available elsewhere. in source-code directories, MacPorts servers, etc. Well, it is the first time in six years I have been caught out… :-( Mind you, I should have upgraded my OSX long ago and none of this would have happened… :-( Cheers, Ian W.
In a mess with libc++ libstdc++ and OSX 10.7.5 Lion
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.
Re: Pallet requires Tcl directory
On 10/04/2017, at 12:43 PM, Ryan Schmidt wrote: > On Apr 9, 2017, at 10:06, db wrote: > >> I checked #43923. Is there any workaround? > > Pallet is broken for many reasons; there are many tickets. Someone needs to > fix the code. There may have been some work done on this in another branch > some time ago that hasn't yet been merged to master… It was in a GSoC project a year or maybe two years ago. Who was the mentor? Who was the student? I don'r recall. Maybe some useful code did not get fully "delivered". Regards, Ian W.
Re: Is Macports down?
On 07/03/2017, at 10:07 AM, Dave Horsfall wrote: > On Mon, 6 Mar 2017, Daniel J. Luke wrote: >> it's working for me right now. > > Hmmm... Still busted here (Australia) so it's either regional or local. > > Any other Aussies on the list? Seems to be working for me --- in Melbourne. Ian W. Tara:~>sudo port selfupdate Password: ---> Updating MacPorts base sources using rsync MacPorts base version 2.3.4 installed, MacPorts base version 2.4.1 downloaded. ---> Updating the ports tree ---> MacPorts base is outdated, installing new version 2.4.1 Installing new MacPorts release in /opt/local as root:admin; permissions 0775 The ports tree has been updated. To upgrade your installed ports, you should run port upgrade outdated
