Re: Can not remove the new MacPorts Mojave package
Hallelujah, I found the answer: http://osxdaily.com/2018/10/09/fix-operation-not-permitted-terminal-error-macos/ -- Sent from: http://mac-os-forge.2317878.n4.nabble.com/MacPorts-Users-f115275.html
Re: Can not remove the new MacPorts Mojave package
On Nov 23, 2018, at 11:18, Dr M J Carter wrote: > On Sat, Nov 10, 2018 at 03:47:26PM -0600, Ryan Schmidt wrote: > >> It's not System Integrity Protection (SIP) either; that applies to >> files Apple provides with the OS, which does not include MacPorts. > > SIP may well care to some extent about users' home directories, as > logging in with a nonexistent homedir causes more fundamental grief > than if it's empty. We get that sometimes with our systems; from > memory, an attempted macOS login with a missing homedir can hang the > OS hard enough to need a reboot, while an empty one can be populated. As far as I know, SIP has nothing to do with your home directory. SIP prevents you from modifying programs, libraries and other files that Apple installed as part of macOS in system directories like /usr and /System. Completely unrelated to that, I'm not surprised that macOS assumes your home directory exists, and that things blow up if it does not, so don't remove your home directory.
Re: Can not remove the new MacPorts Mojave package
On Sat, Nov 10, 2018 at 03:47:26PM -0600, Ryan Schmidt wrote: > It's not System Integrity Protection (SIP) either; that applies to > files Apple provides with the OS, which does not include MacPorts. SIP may well care to some extent about users' home directories, as logging in with a nonexistent homedir causes more fundamental grief than if it's empty. We get that sometimes with our systems; from memory, an attempted macOS login with a missing homedir can hang the OS hard enough to need a reboot, while an empty one can be populated. > Xcode also loves to spawn its simulator service SIGHUPping the simulator causes it to exit, but that didn't solve the problem. > I'm not aware of any changes in MacPorts specific to Mojave that > would relate to the handling of the home directory. So I think the > bug you're investigating is a bug in macOS or Xcode, not MacPorts. Following some heavy net searching today, I found the Full Disk Access pane in Preferences, and discovered sshd has been whitelisted. I've come to the tentative conlusion that this is transitive, in that software run from whitelisted apps (eg stuff launched from an SSH login) will also be whitelisted, while those run via cron will not, hence the Heisenbug nature of the problem but I've been wrong before. After a month of headbanging, I've realised it probably doesn't matter for my purposes if these directories are deleted --- they're empty, and are about to be recreated in any case. Our builds will now complain (in case it turns out to matter later), but continue under protest. Thanks for the feedback, folks. And there, you see, my head no longer throbs. -- G'Kar -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford
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
On Sat, Nov 10, 2018 at 03:47:26PM -0600, Ryan Schmidt wrote: > You could also have the script run `lsof | grep /opt/local` to see > what files in /opt/local/are still open at the time of the > failure. [snip] > Xcode also loves to spawn its simulator service, even though, as far > as I know, MacPorts doesn't make use of it. Maybe the simulator > service in Xcode 10 is doing things with the preferences directory > that it did not on previous versions. Well suggested. Once I removed the "killall -u macports" in the Makefiles and broadened the diagnostics, I found the following, which survived into an interactive session: $ sudo lsof | grep /opt/local [snip] com.apple 85084 macports7r DIR1,4 96 26913415 /opt/local/var/macports/home/Library $ ps auxww | grep -i com.apple [snipissimo] macports 85084 0.0 0.1 4854824 14384 ?? S 2:27pm 0:01.08 /Library/Developer/PrivateFrameworks/CoreSimulator.framework/Versions/A/XPCServices/com.apple.CoreSimulator.CoreSimulatorService.xpc/Contents/MacOS/com.apple.CoreSimulator.CoreSimulatorService 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. PS: There were also odd icon files under /opt/local/libexec/qt5 which iconserviceagent was holding open (from a console login by sysadmin), but /opt/local/libexec no longer existed. I'll worry about whether that matters later; one problem at a time. -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford
Re: Can not remove the new MacPorts Mojave package
On Mon, Nov 12, 2018 at 01:09:29PM -0600, Ryan Schmidt wrote: > Most ports use Xcode make (instead of the one from the gmake port), > so if there were a general problem with Xcode make we probably would > have seen it already. EDESPERATION: See straw, *grasp*. -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford
Re: Can not remove the new MacPorts Mojave package
On Nov 12, 2018, at 04:52, Dr M J Carter wrote: > On Sat, Nov 10, 2018 at 03:47:26PM -0600, Ryan Schmidt wrote: > >> The only file MacPorts always copies into its home directory is the >> Xcode preferences plist. > > Quick note: on our 10.13 build systems, I find that that preferences > file has been saved in the clone of successful nightly builds, but is > missing from the /opt/local that's been cloned. Might the underlying > problem be that I'm using Xcode's make to run the builds? in which > case, mebbe the kludgearound would be to do the purge from one > cronjob, and the full build in another an hour later. Most ports use Xcode make (instead of the one from the gmake port), so if there were a general problem with Xcode make we probably would have seen it already.
Re: Can not remove the new MacPorts Mojave package
On Nov 12, 2018, at 04:15, Dr M J Carterwrote: >> I'm not aware of any changes in MacPorts specific to Mojave that >> would relate to the handling of the home directory. So I think the >> bug you're investigating is a bug in macOS or Xcode, not MacPorts. > > Possibly APFS? that test's pending an upcoming changearound of > hardware. APFS certainly has caused some weird errors already. It caused parallel builds of gcc to fail. We had a fix in place for that for 10.13, but with 10.14, some users have reported the problem resurfacing, despite the fix.
Re: Can not remove the new MacPorts Mojave package
On Sat, Nov 10, 2018 at 03:47:26PM -0600, Ryan Schmidt wrote: > The only file MacPorts always copies into its home directory is the > Xcode preferences plist. Quick note: on our 10.13 build systems, I find that that preferences file has been saved in the clone of successful nightly builds, but is missing from the /opt/local that's been cloned. Might the underlying problem be that I'm using Xcode's make to run the builds? in which case, mebbe the kludgearound would be to do the purge from one cronjob, and the full build in another an hour later. Thanks for that observation. I'll report results once I've results to report. -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford
Re: Can not remove the new MacPorts Mojave package
On Sat, Nov 10, 2018 at 03:47:26PM -0600, Ryan Schmidt wrote: > Since it sounds like you have some kind of Heisenbug that disappears > under later analysis, I'd suggest adding any analysis you can to the > script you're running when it fails. I'm attempting to do that, but with thin results so far. I'll expand the in-build test set from merely lsof on the Prefs directory (which comes up empty) Thanks for the suggestions. > I'm not aware of any changes in MacPorts specific to Mojave that > would relate to the handling of the home directory. So I think the > bug you're investigating is a bug in macOS or Xcode, not MacPorts. Possibly APFS? that test's pending an upcoming changearound of hardware. -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford
Re: Can not remove the new MacPorts Mojave package
On Fri, Nov 09, 2018 at 01:01:42PM -0500, Bill Cole wrote: > Those imply protection by Apple's SIP *or* BSD file flags. That's my suspicion too. > What does 'ls -lORa /opt/local/var/macports/home/' tell you about flags? > (the field after the group, will be '-' if no flags are set.) Absolutely nothing (for completeness, no hard links). Adding the '@' flag shows ~macports's parent (/opt/local/var/macports) has extended attribute info "com.apple.FinderInfo 32" fwiw, but that's set in 10.13 as well, so that's probably an infrared herring. -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford
Re: Can not remove the new MacPorts Mojave package
On Nov 9, 2018, at 10:36, Dr M J Carter wrote: > On Fri, Nov 09, 2018 at 04:05:34PM +0100, Vincent Habchi wrote: >> 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? > > Info from current tests (not yet completed): "whoami" just before the > removal yields "root" under all conditions. > >> Also what >> files are left in /opt/local/var/macports/home/Library/Preferences? > > Completely empty; no fancy permissions either afaict. But by the time > I get to check them, the rm would succeed, so that probably doesn't > tell us much. > >> Any hard link to any other file that could be protected by a sandbox >> mechanism? > > 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 > on, it seems to be of macports's home dir, as the errors change to > "directory not empty" for that dir's parent. > > Hope this helps. More information next week, once the build system > has tried to do a build unattended twice in succession, this time with > exponential backoff between removal attempts. Suggestions for extra > checks to add into the runtime scripting welcomed as you might > gather, this one really has got under my fingernails. Apologies for > any fallout. Since it sounds like you have some kind of Heisenbug that disappears under later analysis, I'd suggest adding any analysis you can to the script you're running when it fails. For example, have the script use `find` to show all the files remaining in /opt/local after the script fails to delete it. If you're root, you should be able to delete anything, so it's not permissions. It's not System Integrity Protection (SIP) either; that applies to files Apple provides with the OS, which does not include MacPorts. You could also have the script run `lsof | grep /opt/local` to see what files in /opt/local/are still open at the time of the failure. The only file MacPorts always copies into its home directory is the Xcode preferences plist. On Mojave you're using Xcode 10, which is of course different from Xcode 9 and earlier. One big change is that the "new build system" is used by default. Since it is not as well tested as the old build system, it may still have bugs. Maybe it is holding the preferences file open where the old build system did not. Xcode also loves to spawn its simulator service, even though, as far as I know, MacPorts doesn't make use of it. Maybe the simulator service in Xcode 10 is doing things with the preferences directory that it did not on previous versions. You might even investigate having your build script kill the simulator service (com.apple.CoreSimulator.CoreSimulatorService) to see if that clears up the problem. I'm not aware of any changes in MacPorts specific to Mojave that would relate to the handling of the home directory. So I think the bug you're investigating is a bug in macOS or Xcode, not MacPorts.
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 5: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 Those imply protection by Apple's SIP *or* BSD file flags. What does 'ls -lORa /opt/local/var/macports/home/' tell you about flags? (the field after the group, will be '-' if no flags are set.)
Re: Can not remove the new MacPorts Mojave package
On Fri, Nov 09, 2018 at 04:05:34PM +0100, Vincent Habchi wrote: > 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? Info from current tests (not yet completed): "whoami" just before the removal yields "root" under all conditions. > Also what > files are left in /opt/local/var/macports/home/Library/Preferences? Completely empty; no fancy permissions either afaict. But by the time I get to check them, the rm would succeed, so that probably doesn't tell us much. > Any hard link to any other file that could be protected by a sandbox > mechanism? 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 on, it seems to be of macports's home dir, as the errors change to "directory not empty" for that dir's parent. Hope this helps. More information next week, once the build system has tried to do a build unattended twice in succession, this time with exponential backoff between removal attempts. Suggestions for extra checks to add into the runtime scripting welcomed as you might gather, this one really has got under my fingernails. Apologies for any fallout. -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford
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
Re: Can not remove the new MacPorts Mojave package
On Fri, Nov 09, 2018 at 10:31:39AM +, Dr M J Carter wrote: > Please find enclosed the logfile for this morning's attempt Sigh: said logfile. -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford # Info: git: ## majoc-build-maint...origin/majoc-build-maint # Info: git: * e28aae0 WIP: add a killall for dangling processes. # Info: git: * 8258b20 Oneliner: another unescaped newline. # Info: git: * 0758a92 Oneliners: backslash-escape newlines. # Info: git: * 86c468e WIP: further scorched-earth debugging. # Info: git: * c31e29b Mark g95 known-MIA. +++ nightly-build starting (Fri Nov 9 03:42:07 GMT 2018) Pass, central.unlocked_q. +++ nightly-build.lock_engage: nightly-build 2018-11-09 03.42.07 10_14 +++ make nightly-build-core (Fri Nov 9 03:42:07 GMT 2018) +++ nightly-build-core starting (Fri Nov 9 03:42:07 GMT 2018) +++ empty-build-inner starting (Fri Nov 9 03:42:08 GMT 2018) +++ unload-agents-daemons starting (Fri Nov 9 03:42:08 GMT 2018) +++ Purging agents (Fri Nov 9 03:42:08 GMT 2018) +++ Unload agent org.macports.startx: /Library/LaunchAgents/org.macports.startx.plist: Could not find specified service +++ Unload agent org.freedesktop.dbus-session: /opt/local/etc/LaunchAgents/org.freedesktop.dbus-session/org.freedesktop.dbus-session.plist: Could not find specified service +++ Purging daemons (Fri Nov 9 03:42:08 GMT 2018) +++ Unload daemon org.macports.ganglia: /opt/local/etc/LaunchDaemons/org.macports.ganglia/org.macports.ganglia.plist: Could not find specified service +++ Unload daemon org.macports.mongodb: /opt/local/etc/LaunchDaemons/org.macports.mongodb/org.macports.mongodb.plist: Could not find specified service +++ Unload daemon org.macports.privileged_startx: +++ Unload daemon org.macports.redis: /opt/local/etc/LaunchDaemons/org.macports.redis/org.macports.redis.plist: Could not find specified service +++ Unload daemon org.macports.rsyncd: /opt/local/etc/LaunchDaemons/org.macports.rsyncd/org.macports.rsyncd.plist: Could not find specified service +++ Unload daemon org.macports.slapd: /opt/local/etc/LaunchDaemons/org.macports.slapd/org.macports.slapd.plist: Could not find specified service +++ Unload daemon org.freedesktop.dbus-system: +++ unload-agents-daemons finished (Fri Nov 9 03:42:08 GMT 2018) +++ Uninstall -u (Fri Nov 9 03:42:08 GMT 2018) +++ Uninstall all (Fri Nov 9 03:42:09 GMT 2018) Error: Failed to deactivate font-misc-ethiopic: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_registry_portfiles_font-misc-ethiopic-1.0.3_0_1528f7e45ad1d64006874366c2d8aea0b2e7490298bdfc573d1282fd7c7c1d75-1770/font-misc-ethiopic/main.log for details. Warning: Failed to execute portfile from registry for font-misc-ethiopic @1.0.3_0 +++ Uninstall done (Fri Nov 9 03:48:47 GMT 2018) killall -TERM -u macports || echo "+++ Error: problems with killall" sleep 5 rm -rf /Applications/MacPorts/* for strike in 1 2 3 4 5 out ; do \ if [ -z "`echo /opt/local/*`" ] ; then \ echo "+++ Info: dir empty" ; \ exit 0 ; \ elif rm -rf /opt/local/* ; then \ echo "+++ Info: rm succeeded" ; \ exit 0 ; \ else \ echo "+++ Info: Strike $strike" ; \ [ "$strike" != "out" ] || exit 1 ; \ sleep 5 ; \ fi ; \ done 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 +++ Info: Strike 1 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 +++ Info: Strike 2 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 +++ Info: Strike 3 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 +++ Info: Strike 4 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 +++ Info: Strike 5 rm: /opt/local/var/macports/home/Library/Preferences: Operation not permitted rm: /opt/local/var
Re: Can not remove the new MacPorts Mojave package
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 > > mymbp:~ slgarwood$ > > *Exactly* what command are you running ? Are you running it through sudo ? > (your regular user account will not be owning /opt/local) I can reproduce this exactly and repeatedly, and I've been banging my head on it for a fortnight. Our nightly build scripts succeed once, but the next attempt fails to remove the above directory, and the build dies aborning. The actions in the Makefiles, shorn of interlocks and safety traps, boil down to: # disable any MacPorts daemons port -u uninstall # succeeds port -q uninstall all # succeeds killall -TERM -u macports # succeeds rm -rf /Applications/MacPorts/* # succeeds for strike in 1 2 3 4 5 out ; do \ if [ -z "`echo /opt/local/*`" ] ; then \ echo "+++ Info: dir empty" ; \ exit 0 ; \ elif rm -rf /opt/local/* ; then \ echo "+++ Info: rm succeeded" ; \ exit 0 ; \ else \ echo "+++ Info: Strike $strike" ; \ [ "$strike" != "out" ] || exit 1 ; \ sleep 5 ; \ fi ; \ done # fails This is all done by a sargasso of Makefiles and shell scripts, kicked off in the background using either sudo or root's crontab. (I'll leave my adventures with atrun for another day.) Please find enclosed the logfile for this morning's attempt, which shows a failure to uninstall font-misc-ethiopic (which may or may not be relevant). My current theory stems from noting that the offending directory is ~macports/Library/Preferences, hence the killall above; but by the time I get to see the result, whatever process is holding down that directory is long gone (so a reattempt would succeed). Frustratingly, an empty build fails to fail, and a full build takes twelve hours or more; as Mr Micawber would say, "result Misery". I'm doing a reduced test build as we speak, after which I'll try running the offending Make target by hand using sudo. All suggestions welcomed: we can't roll out Mojave in production till this is fixed or worked around. Thanks in advance. -- Dr Martin J Carter Computer System Administrator Astrophysics, University of Oxford
Re: Can not remove the new MacPorts Mojave package
*Exactly* what command are you running ? Are you running it through sudo ? (your regular user account will not be owning /opt/local) Chris 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 mymbp:~ slgarwood$
Can not remove the new MacPorts Mojave package
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 mymbp:~ slgarwood$
