> Wouldn't "${configure.cc} -E" be a sensible value?
>>>
With gcc, that doesn't behave quite the same as running cpp. So probably
not if clang is maintaining gcc compatibility in this respect.
>>>
>>> How would the port compile out of Macports if only clang (say Xcode
>>> 4.2) were
On Wed, Feb 22, 2012 at 02:39:42AM +1100, Joshua Root wrote:
> And why did Dan set the ownership in the first place? I can see that
> making sense in the per-port dirs but not really in the global one.
Without it, the plist had 0600 permissions and it was owned by root, so
xcodebuild couldn't acce
> Is there any data created by MacPorts that could be used in determining the
> first install date and last install/upgrade date for an installed port?
>
> Or a logging facility for port install, upgrade, activate, deactivate and
> uninstall?
To a degree, the registry has some date information:
Is there any data created by MacPorts that could be used in determining the
first install date and last install/upgrade date for an installed port?
Or a logging facility for port install, upgrade, activate, deactivate and
uninstall?
Regards,
Bradley Giesbrecht (pixilla)
__
Running 'sudo xcodebuild' should've saved the "agreed-to" bits in /Library as
opposed to your own ~/Library, but it looks like it will only do that if you
haven't agreed to it already as the user. You should be able to work around
that issue by first "unaccepting" the agreement. Please give th
On Tue, Feb 21, 2012 at 05:45:48PM +0100, Clemens Lang wrote:
> Yeah, that should probably be fixed. It's just a cosmetic issue,
> though.
>
> […]
>
> I'm not sure, but I'm pretty sure the change that set the file
> permissions is bogus:
> --wr-T 1 macports admin 20K Feb 21 03:07 com.appl
On Wed, Feb 22, 2012 at 02:39:42AM +1100, Joshua Root wrote:
> Or go back to always copying (when possible). If we don't care whose
> plist it is though, we might as well just create one with the right
> keys to let us run and dispense with the copying.
If we just create a plist the user didn't ac
On 2012-2-22 01:01 , Clemens Lang wrote:
> On Wed, Feb 22, 2012 at 12:22:46AM +1100, Joshua Root wrote:
>> What if the user running port is not the user who ran it last time?
>
> MacPorts might be getting the wrong Xcode.plist then, but is this really
> an issue? To fix this we would have to store
When we update the documentation for the next release, be sure to include all
the disk images that might be needed (or download options from within xcode):
Xcode [1] for the majority of the build chain, Command Line Tools [2] for
xcodebuild and Auxiliary Tools for Xcode [3] for PackageMaker.
1
On Wed, Feb 22, 2012 at 12:22:46AM +1100, Joshua Root wrote:
> What if the user running port is not the user who ran it last time?
MacPorts might be getting the wrong Xcode.plist then, but is this really
an issue? To fix this we would have to store where we copied the plist
from.
> Also, the proc
On 2012-2-21 12:52 , cal at macports.org wrote:
> Revision: 90075
> http://trac.macports.org/changeset/90075
> Author: cal at macports.org
> Date: 2012-02-20 17:52:09 -0800 (Mon, 20 Feb 2012)
> Log Message:
> ---
> Only copy com.apple.dt.Xcode.plist to temporary user directo
On Feb 21, 2012, at 4:59 AM, Joshua Root wrote:
> On 2012-2-21 20:46 , Dan Ports wrote:
>> On Tue, Feb 21, 2012 at 05:48:44PM +1100, Joshua Root wrote:
>>> It seems that the subversion port doesn't know about the Apple-supplied
>>> root certs, and it's really inconvenient to put a config file in
>>
I took my problem up on the dovecot mailing list.
And was advised to try the following:
>Try attaching gdb into it:
>
>gdb -p
>bt full
4604ds1-ynoe:~ root# ps -axj | grep dovecot
root 40655 1 40655 4d847500 Ss ??0:00.02
/macports/sbin/dovecot -c /macports/etc/dovecot/dovecot.c
On 2012-2-21 20:46 , Dan Ports wrote:
> On Tue, Feb 21, 2012 at 05:48:44PM +1100, Joshua Root wrote:
>> It seems that the subversion port doesn't know about the Apple-supplied
>> root certs, and it's really inconvenient to put a config file in
>> /opt/local/var/macports/home. /usr/bin/svn might do
On Tue, Feb 21, 2012 at 05:48:44PM +1100, Joshua Root wrote:
> It seems that the subversion port doesn't know about the Apple-supplied
> root certs, and it's really inconvenient to put a config file in
> /opt/local/var/macports/home. /usr/bin/svn might do better.
/usr/bin/svn is going to be svn 1.
15 matches
Mail list logo