Re: Build servers offline due to failed SSD
Hi, Wouldn’t it make sense to use some sort of RAM caching to speed up builds instead of SSD? What’s the point of using a permanent storage device for something that is bound to be erased in a very short time? Maybe I’m way off base, though. V.
Re: hints for porting sunrpc programs to macOS?
> Are there any MODERN sunrpc service libraries that have been ported to macOS, > or any other solutions? Or anyplace else I'd be likelier to find an answer? > :-) Aren't rpc services SYS V anyway? I thought they had been deprecated after the death of the yellow pages service. Was prolly wrong. I am not aware of any RPC library running on MacOS, but that doesn’t mean one doesn’t exist. Vincent
Re: Dependency untangling riddle
> Is there a concept of "python-stable" versus "python-newest" like there is > the -devel versions? I don’t think so? In my case, it turns out there were three “problematic” ports: gobject-introspection, fonttools and libpsl. All have python 3.7 hardcoded into their Portfile, so it’s not possible to use any other python version. They ought to be updated to allow for variant use. py-brotli I upgraded to use python 3.8, I’m going to commit the wart. Cheers, Vincent
Dependency untangling riddle
Hi again, this time, I have another interesting quandary. When I try to install LyX, I get this message: — Air > sudo port install LyX +python38 ---> Computing dependencies for LyX The following dependencies will be installed: […] py37-beaker py37-mako py37-markdown py37-markupsafe py37-setuptools python37 […] Continue? [Y/n]: — So basically I have a long list of dependents to install, one (or more) of which itself/themselves depend(s) on python 3.7, at least in its/their default version(s). Since I don’t want to have python3.7 installed alongside python3.8, how can I find out (easily) which port(s) in the list is/are requiring python37? Thanks, Vincent
Why does qt5-qttools depends on clang 9?
Hi there, everything is in the subject. Is there any reason for this dependency? I’m trying to get rid of python 2.7, and the only dependent port left so far is clang 9.0, which is needed by qt5-qttools, but I can’t figure out why. Thanks a bunch, Vincent
Re: Xcode update broke ports
> I think it is port-dependent. Some ports worked fine with the symlink, but > some (e.g., gcc) failed due to differences in the headers from what they were > expecting. Oh, okay, right, makes sense. Have fun, Vincent
Re: OpenCL deprecation in MacOS 10.14
> On 1 Sep 2019, at 12:26, Mojca Miklavec wrote: > > I have 10.13, but it should be present in 10.14. Maybe it disappeared with > 10.15. Even on 10.13 I could not make fft work with gpu using my own program > though (but the headers were there), it only worked with cpu. Apparently, 10.14.6 ditched it. I had no problem compiling the previous version of GDAL with OpenCL, but right now, it’s gone. What you say to me rings a bell as to why some utilities build on GDAL used to crash. I’m taking your word for it, and I think the best way is indeed to put out that +opencl variant to pasture. Thanks a bunch Mojca! Vincent
OpenCL deprecation in MacOS 10.14
Folks, I’m currently upgrading the GDAL port to 3.0.1 and… the OpenCL code doesn’t work anymore. No way I can find the file OpenCL.h anywhere in the system. I suppose this is part of Apple policy of deprecating OpenCL, so that no one can build new software based on it. Could you confirm that OpenCL.h has also disappeared from the /System/Library/Framework on your machines (as of 10.14.6)? In which case, I’m going to pull out the +opencl variant from the new Portfile. Thanks a bunch, Vincent
Re: Gimp doesn't start
> Christophs-MBP:MacOS kuku$ pwd > /Applications/MacPorts/GIMP.app/Contents/MacOS > Christophs-MBP:MacOS kuku$ ls > GIMP > Christophs-MBP:MacOS kuku$ file GIMP > GIMP: Mach-O 64-bit executable x86_64 > Christophs-MBP:MacOS kuku$ ./GIMP > 2018-11-28 08:23:18.176 GIMP[86714:1924234] Failed to connect (cancelButton) > outlet from (ScriptExecController) to (NSButton): missing setter or instance > variable > 2018-11-28 08:23:18.176 GIMP[86714:1924234] Failed to connect > (messageTextField) outlet from (ScriptExecController) to (NSTextField): > missing setter or instance variable > Anzeige kann nicht geöffnet werden: Nah. This is not X11 related but Cocoa-. It means the underlying handling code for some UI elements is missing, which is rather strange. When you launch GIMP, do you (briefly) see the X11 icon popping up? Did you installed GTK3 with the +quartz variant too? Viel Glück :/ V.
Re: Gimp doesn't start
> macOS mojave 10.14.1. > > I did a port install gimp. In the end the icon is there in the Apps launcher. > Clicking on the icon results in nothing happening. Try to launch it from Terminal and look for error messages. Say, like, typing a line like this at the prompt (note that “Gimp.app” is a wild guess): /Applications/MacPorts/Gimp.app/Contents/MacOS/Gimp.app (use the TAB key to trigger autocompletion) Also, did you install X11? I’m not 100% certain, but last time I checked GIMP still needed X11 to run. V.
Re: Can not remove the new MacPorts Mojave package
> On 16 Nov 2018, at 13:05, Dr M J Carter > wrote: > > Bingo, for sufficiently provisional values of Bing. Much thought > needed on which of several approaches to take next, and I'll need to > guard against premature rejoicing, but it's the first substative Clue > I've seen yet. Wish me luck, folks. Good luck! :) Don’t forget to tell us if Oumuamua is an extraterrestrial probe or not ;) Vincent
Re: Can not remove the new MacPorts Mojave package
Hi again, > rm: /opt/local/var/macports/home/Library: Operation not permitted > rm: /opt/local/var/macports/home: Operation not permitted Both lines are very suspect. When I ls what’s inside the first directory Air > ll /opt/local/var/macports/home/Library/Preferences/ total 616 -rw-r--r-- 1 macports admin 314139 7 Nov 18:33 com.apple.dt.Xcode.plist This looks to me very much like a hardlink or a protected file. Air > ls -lORa /opt/local/var/macports/home/Library/Preferences/ total 616 drwxr-xr-x 3 root admin - 96 8 Nov 14:53 . drwxr-xr-x 3 root admin - 96 25 Oct 2016 .. -rw-r--r-- 1 macports admin - 314139 7 Nov 18:33 com.apple.dt.Xcode.plist But that doesn’t mean anything in my case, since I have disabled SIP for files (yes, I got rid of several dumb apps such as Chess or Stocks, I only have a 128 MB SSD). > No hard links that I spotted (but would that not fail under 10.13? the > same code runs fine). The only differences between what fails and > what works are 10.14 vs 10.13 and older, and [sound effect: penny > dropping] APFS vs HFS+ journaled. If there's some protection going SIP protection might have been extended to newer files between 10.13 and 10.14. Vincent
Re: Can not remove the new MacPorts Mojave package
On 9 Nov 2018, at 11:31, Dr M J Carter wrote: > > On Wed, Oct 03, 2018 at 01:25:28PM +0100, Chris Jones wrote: >> On 03/10/18 13:16, S. L. Garwood via macports-users wrote: >>> I installed the new Macports bundle mentioned in Josha Root’s email. >>> Install went fine, but now it will not uninstall — doing the “rm” >>> commands in /opt/local gets a series of errors >>> >>> rm: /opt/local/var/macports/home/Library/Preferences: Operation not >>> permitted >>> rm: /opt/local/var/macports/home/Library: Operation not permitted >>> rm: /opt/local/var/macports/home: Operation not permitted >>> rm: /opt/local/var/macports: Directory not empty >>> rm: /opt/local/var: Directory not empty >>> rm: /opt/local: Directory not empty Did you check the script was executed with root privilege? Also what files are left in /opt/local/var/macports/home/Library/Preferences? Any hard link to any other file that could be protected by a sandbox mechanism? Vincent
Heads-up: PROJ
Hey there,
I’m going to commit a major overhaul to the “proj” port. Currently, “proj” is
split between proj47 and proj, the latter corresponding to proj 5.0.0 recently
released.
The problem is this:
• Proj 5.0.0 is buggy, unusable at least with QGis until a bugfix version is
out;
• Proj and proj47 can be installed together, but since proj installs its files
in ${prefix} whereas proj47 does in ${prefix}/lib/proj${version}/…, even if
proj47 location is specified in the Portfile, because of the order in which -I…
include paths are emitted at compile time, the compiler ends up seeing always
proj include files instead of proj47;
• Proj47 is obsolete, latest proj4 version is 4.9.3.
What I am going to do:
• Rename proj47 port into proj4 and update it to proj 4.9.3;
• Change the proj Portfile so that it installs files in ${prefix}/lib/proj5, in
such a way that both proj4 and proj(5) can be used simultaneously without
conflicting;
• Update all portfiles that currently depend on proj → proj4, until a suitable
proj 5 bug fix version is released.
What I could do:
• Rename proj into proj5. Does anyone objects to this?
Cheers
Vincent
Re: QGIS and GRASS 7.4.0
> It looks like the QGIS port needs an update. > https://raw.githubusercontent.com/qgis/QGIS/final-2_18_16/ChangeLog indicates > that 2.18.14 (the current port version) was released 2017-10-27 but grass74 > support didn't get done until 2017-11-18. > > I have found that opening tickets for updates to existing ports is useful for > getting updates done. I apologise because I sort of put QGIS aside while concentrating on the QGIS 3 port, which should be released any day now. I’m afraid I took the opportunity of jumping to QGIS 3 to remove all legacy software that I had to leave installed because of QGIS 2, such as Qt4 and Python 2.7, because I have a very small SSD on my MacBook Air, and having both Qt4 and Qt5 alongside consumed a lot of space. I think I still have another machine with QGIS/Python 2/QT 4 installed, but unfortunately I’m just about to begin a week long holiday and won’t have that machine at hand before I return next week. So if that can wait that long… I apologise for the inconvenience. Vincent
Re: meltdown and spectre
Hey folks, for Meltdown, MacOS 10.13.2 is already patched and secure. As for Spectre, LLVM developers have committed a workaround (it’s a bit complex to detail here) for 5/6 which should be back ported. Whomever is responsible for LLVM should be on the lookout for the new versions to appear anytime soon. Vincent
