Re: moving install dir back to /opt/local : what config files to edit?
On Mar 16, 2014, at 20:13, Jeremy Lavergne wrote: You might consider checking that the destination of your symlink has appropriate permissions. My guess is something over there no longer matches up. You could have had a point with permissions of the symlink, but in the end the issue was simply the sandboxing feature. Switching that off everything worked as expected with the symlink in place. And that's probably the feature that obliged me to normalise the paths in macports.conf about 7 months back ... R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: clang memory usage vs. gcc (and OS X 10.8, 10.9, ...)
Hi, On Mar 16, 2014, at 18:05, Chris Jones wrote: Well yes, of course. I was thinking as much as a test, to see if its the optimisations that are the issue, as it is for me, than as a solution. In my case i simply could not compile at all without -O0... without it, the memory usage hit around 9GB before being killed by our nightly regression testing framework. If your case is not so bad and you can get by, then fine Anyway, on #calligra someone just claimed he got about 1200MB peak memory usage building gmic.cpp with Apple's clang-3.4 . If someone else can confirm that the issue is rather moot (meaning I can continue to use g++ for just this file on 10.6 ... ) ___ I've just been testing this a bit on my 10.9.2 VM with the latest Xcode (5.1, clang 3.4svn) installed. That VM has only 2.5GB of RAM (which it sees as 4GB, curiously). Still, gmic.cpp compiles much better with clang++ on that set-up (haven't tested clang-mp-3.3) though g++ still uses less memory (1.2 vs 1.4GB real peak) and completes about twice as quick. However, things go downhill again with clang 3.5 (from MacPorts). I've seen a peak real mem. usage of 1.75GB, and it is now sitting at 10%CPU with around 200MB real memory, but with red memory pressure and 1.72GB total compressed memory. If you feel like filing reports against a current clang version, you might want to check the 3.5 version on your code... R. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: qt4-mac : still dependent on Carbon.framework?
On Sun, Mar 16, 2014, at 09:36 PM, René J.V. Bertin wrote: On Sunday March 16 2014 18:42:53 you wrote: about for some project that's using QtGui via QMake, for which removing the linking with Carbon worked? I've never tried the former, and the latter could easily work depending on the project. - MLD Yes, and we're talking about a number of the KDE apps I built manually. Of course, projects that use Carbon functions would need to link the framework, but it would appear that the other apps don't have that requirement. No great surprises there: If you project does not use Carbon, then you don't need to link to it. If the project does use Carbon, it must be included in linking. That said, if you're linking a project with QtGui, which in turn links with Carbon, then it won't hurt to also link the project with Carbon too. None of the library description files (.la, .prl, .pc) include Carbon in their dependency for linking with QtGui ... so, I'm not sure where the dependency is coming from. Anyway, hope this helps. - MLD ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
sandboxd message
Hi: I re-purposed a Core2 Duo mini running 10.7.5 over the weekend. I'm trying to set up Time Machine to backup the machine and it is running very slowly (est 20+ hours for a 56 GB backup). It may not be related to the slow Time Machine backup, but I'm getting the following Console message periodically: 14-03-17 12:49:00.695 PM sandboxd: ([1508]) mdworker(1508) deny file-write-create /opt/local/var/macports/home/Library/Preferences/com.apple.LaunchServices.plist.lockfile The file /opt/local/var/macports/home/Library/Preferences/com.apple.LaunchServices.plist.lockfile does not exist. Neither does /opt/local/var/macports/home/Library/Preferences/com.apple.LaunchServices.plist Strangely enough, I have set Spotlight to ignore everything under /opt, so I'm not sure why mdworker is looking in there. I have run Disk Utility's verify disk a couple of times, no problems found. Can anyone shed some light? Craig ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: taskgated: no signature
On 18 Mar 2014, at 3:00 am, macports-users-requ...@lists.macosforge.org wrote: Yeah, that was all I meant by saying on Mountain Lion and higher was that it was conditionally declared like that; I did *not* mean to imply that I was on Mountain Lion myself... (I am actually still on Snow Leopard so `port notes gdb-apple` says the same thing for me as it did for Ian; I only knew about them because I have been working on my own copy of the Portfile recently...) And shock horror gasp if you ever ‘upgrade’ you can’t go back, even if you have the install CDs (All about expired certificates for xcode) (I tried MBR and UEFI versions of various linux, always putting OSX back, so I installed Snow Leopard from CD 3 or 4 times, ha ha not any more) James ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: taskgated: no signature
On 17/03/2014, at 8:51 AM, Eric Gallager wrote: Yeah, that was all I meant by saying on Mountain Lion and higher was that it was conditionally declared like that; I did not mean to imply that I was on Mountain Lion myself... (I am actually still on Snow Leopard so `port notes gdb-apple` says the same thing for me as it did for Ian; I only knew about them because I have been working on my own copy of the Portfile recently...) On my system (Lion), the plist file referred to in the Macports notes, /System/Library/LaunchDaemons/com.apple.taskgated.plist, already contains the required keyProgramArguments/key sequence for choosing the -s and -p options when taskgated executes, i.e. Apple is phasing in the taskgated security check, which becomes fully effective in Mountain Lion+ presumably. Two further questions: 1. The check seems to be to prevent a program from starting a foreign process that could compromise the O/S (e.g. spyware?). In the long term, should MacPorts be recomending bypassing it with the -p and -s options? I presume this is what MacPorts is doing. 2. This is off-topic but I hope someone can help. Here is what man taskgated says. -p Accepts the old (Tiger) convention that a process with a pri- mary effective group of procmod or procview is allowed to get task ports. Without this option, this legacy mode is not sup- ported. -s Allow signed applications marked as safe to have free access to task ports, without having to pass an authorization check. Note that such callers must be marked both allowed and safe. Although I used to be a UNIX guru/sysadmin in a former life, I do not understand much of the language used here, specifically effective group of procmod or procview, signed applications, marked as safe and marked both allowed and safe. So what would I really need to do here? The Console log message I keep getting is: 17/03/14 12:35:27.355 PM taskgated: no signature for pid=1169 (cannot make code: host has no guest with the requested attributes) I am asking all this because it may have a bearing on why KDE apps sometimes fail to start in a MacPorts and OS X environment. Also I am trying to gain a better understanding of how KDE apps operate internally, particularly if they have plugins or KParts. There are two versions of my app, the MacPorts-installed version and my development version. The MacPorts version can start a KDE plugin as a separate UNIX-type process but my development version could not. I have just now found a solution, but I do not really understand (yet) why it works. I usually run test-shots from the command-line, UNIX-style: PalapeliBuild:palapeli ./src/palapeli.app/Contents/MacOS/palapeli The OS X version of my KDE CMake and make procedures installs apps in /Applications/KDE4/appname.app. So, instead of the above, I tried: PalapeliBuild:palapeli open /Applications/KDE4/palapeli.app The plugin then ran OK, but I still got that pesky taskgated message and my debugging output all went to the Console of course. All the best, Ian W. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: clang memory usage vs. gcc (and OS X 10.8, 10.9, ...)
On 18 Mar 2014, at 3:00 am, macports-users-requ...@lists.macosforge.org wrote: Well yes, of course. I was thinking as much as a test, to see if its the optimisations that are the issue, as it is for me, than as a solution. In my case i simply could not compile at all without -O0... without it, the memory usage hit around 9GB before being killed by our nightly regression testing framework. If your case is not so bad and you can get by, then fine Anyway, on #calligra someone just claimed he got about 1200MB peak memory usage building gmic.cpp with Apple's clang-3.4 . If someone else can confirm that the issue is rather moot (meaning I can continue to use g++ for just this file on 10.6 ... ) ___ I've just been testing this a bit on my 10.9.2 VM with the latest Xcode (5.1, clang 3.4svn) installed. That VM has only 2.5GB of RAM (which it sees as 4GB, curiously). Still, gmic.cpp compiles much better with clang++ on that set-up (haven't tested clang-mp-3.3) though g++ still uses less memory (1.2 vs 1.4GB real peak) and completes about twice as quick. However, things go downhill again with clang 3.5 (from MacPorts). I've seen a peak real mem. usage of 1.75GB, and it is now sitting at 10%CPU with around 200MB real memory, but with red memory pressure and 1.72GB total compressed memory. If you feel like filing reports against a current clang version, you might want to check the 3.5 version on your code... Somewhat OT so would you mind mailing me directly (unless of interest here) I’ve tried a few times to install a VM on my iMac 27. I dont recall detail but every install failed with VirtualBox *except* the hacked snow leopard install that I can install on any hardware … Snow_Leopard_Client_Server_10.6.2_SSE2_SSE3_Intel_AMD_by_Hazard.iso So … what did you do and how? Thanks James ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: taskgated: no signature
On Mon, Mar 17, 2014 at 8:50 PM, Ian Wadham iandw...@gmail.com wrote: 1. The check seems to be to prevent a program from starting a foreign process that could compromise the O/S (e.g. spyware?). In the long term, should MacPorts be recomending bypassing it with the -p and -s options? I presume this is what MacPorts is doing. I get the impression -s is needed if you want to attach to processes with a debugger or dtrace; as such it is appropriate for development systems. 2. This is off-topic but I hope someone can help. Here is what man taskgated says. -p Accepts the old (Tiger) convention that a process with a pri- mary effective group of procmod or procview is allowed to get task ports. Without this option, this legacy mode is not sup- ported. -s Allow signed applications marked as safe to have free access to task ports, without having to pass an authorization check. Note that such callers must be marked both allowed and safe. Although I used to be a UNIX guru/sysadmin in a former life, I do not understand much of the language used here, specifically effective group of procmod or procview, signed applications, marked as safe and marked both allowed and safe. procmod and procview are groups (/etc/groups on Unix, `dscl . list Groups` on OS X). The primary effective group ID is Apple saying must be the egid, not just in the group vector. (If your former life was long enough ago to be pre-SVR4, you might not know about group vectors; they're from BSD. In short, you have not only a primary group affiliation in your egid but an additional vector of groups of which you are a member; you can switch the egid between any of the groups in your group vector without requiring elevated permissions. Only root can set the group vector, just as only root can change to an arbitrary gid. Files are created with the primary egid, but file group access checking checks egid and the group vector.) The others are Apple-isms; applications can be signed with an X.509 certificate. I'll leave the rest to someone who knows more about the specific details of Apple's code signing. `man codesign` might be somewhat enlightening, or might not. The Console log message I keep getting is: 17/03/14 12:35:27.355 PM taskgated: no signature for pid=1169 (cannot make code: host has no guest with the requested attributes) Again related to code signing; apparently that's taskgated-ese for I couldn't find the kind of code signature I was looking for. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: taskgated: no signature
Thanks, Brandon. You have given me some leads I can get my teeth into … or google. And you dated me pretty accurately re SVR4. I knew quite a bit about UNIX before that, but System V Release 4 was my first hands-on experience --- 1989-1998, with H-P, Sun, Prime and ICL. Cheers, Ian W. On 18/03/2014, at 12:36 PM, Brandon Allbery wrote: On Mon, Mar 17, 2014 at 8:50 PM, Ian Wadham iandw...@gmail.com wrote: 1. The check seems to be to prevent a program from starting a foreign process that could compromise the O/S (e.g. spyware?). In the long term, should MacPorts be recomending bypassing it with the -p and -s options? I presume this is what MacPorts is doing. I get the impression -s is needed if you want to attach to processes with a debugger or dtrace; as such it is appropriate for development systems. 2. This is off-topic but I hope someone can help. Here is what man taskgated says. -p Accepts the old (Tiger) convention that a process with a pri- mary effective group of procmod or procview is allowed to get task ports. Without this option, this legacy mode is not sup- ported. -s Allow signed applications marked as safe to have free access to task ports, without having to pass an authorization check. Note that such callers must be marked both allowed and safe. Although I used to be a UNIX guru/sysadmin in a former life, I do not understand much of the language used here, specifically effective group of procmod or procview, signed applications, marked as safe and marked both allowed and safe. procmod and procview are groups (/etc/groups on Unix, `dscl . list Groups` on OS X). The primary effective group ID is Apple saying must be the egid, not just in the group vector. (If your former life was long enough ago to be pre-SVR4, you might not know about group vectors; they're from BSD. In short, you have not only a primary group affiliation in your egid but an additional vector of groups of which you are a member; you can switch the egid between any of the groups in your group vector without requiring elevated permissions. Only root can set the group vector, just as only root can change to an arbitrary gid. Files are created with the primary egid, but file group access checking checks egid and the group vector.) The others are Apple-isms; applications can be signed with an X.509 certificate. I'll leave the rest to someone who knows more about the specific details of Apple's code signing. `man codesign` might be somewhat enlightening, or might not. The Console log message I keep getting is: 17/03/14 12:35:27.355 PM taskgated: no signature for pid=1169 (cannot make code: host has no guest with the requested attributes) Again related to code signing; apparently that's taskgated-ese for I couldn't find the kind of code signature I was looking for. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: usage numbers for macports vs. homebrew?
On Mar 12, 2014, at 2:12 PM, Art McGee amc...@gmail.com wrote: The problem is that the presentation of the case for supporting MacPorts was confusing and unconvincing, so usage statistics are not going to help in that matter. I’ve been wondering why Homebrew has such huge momentum and mindshare these days. In random places on the web I’ve seen people imply that it’s better/more reliable than Macports. (The only concrete example was terribly outdated, about TexLive version about four years ago.) I’ve given Homebrew a quick try in a VM and it doesn’t seem that different in functionality. (Except that I do wish we had something like Homebrew-cask.) So, other than the coolness factor (which I guess comes partly from being “the new thing”, and partly from using Github for all development and distribution), what else is there? Try to keep it factual and based on your own experiences using/administering both, please. Davor___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
glib user_data_dir set to /opt/local/share
I’m on Mavricks with MacPorts 2.2.1 I recently upgraded the meld port (@1.8.4), and now when ever I try to run it, it blows up with an OSError. (OSError: [Errno 13] Permission denied: '/opt/local/share/meld/recent-NbPmhP.meldcmp’ ) Looking into it, it appears that the problem is that meld wants to write a tempfile to the user_data_dir specified by glib. (See line 53 in /opt/local/lib/meld/meld/recent.py ) I don’t believe user_data_dir is set correctly. This call is intended to get a directory for user-specific data, not a system-wide directory. (See https://developer.gnome.org/glib/2.37/glib-Miscellaneous-Utility-Functions.html#g-get-user-data-dir). I’m not sure which glib meld is using, but I’ve got glib1 @1.2.10 and glib2 @2.38.2 0) Is anyone else seeing this? I suspect this is happening for all ports that rely on glib. 1) This needs to be fixed. And I suspect the fix needs to be in the underlying glib port 2) Does anyone know a work around, beyond setting /opt/local/share to be world writeable? Thanks. -- jonathankoren jonat...@robotmonkeys.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
