Re: /etc/paths

2015-02-07 Thread Luc Bourhis

>> (1) We consider /etc/paths to be a "system file". We don't like modifying 
>> system files.
>> (2) Modifying /etc/paths affects all users' settings, which is undesirable.
> 
> Actually it is desirable, or it has at least been desired by some users, e.g.:
> 
> https://trac.macports.org/ticket/36323

Note that it was suggested in this discussion you linked to add files in 
/etc/paths.d but that would not do what many users want because the paths 
listed in  /etc/paths are put first in PATH and then those from  /etc/paths.d 
are appended. Since  /etc/paths lists /bin, /user/bin, etc by default, Macports 
paths would not override system ones. I like it the other way around and I am 
not the only one I think.

I am happy to see that my initial noise led to informative a discussion after 
all ;-)

And then there the orthogonal issue of Apps launched from the Finder which get 
PATH from launchd and for which neither path_helper nor shell startup files 
help. Once upon a time, I hacked a solution with a daemon watching .bashrc and 
friends to keep the PATH of the shell and that of launchd in synch but 
eventually I gave up and just launched the PATH-sensitive Apps with "open" from 
the Terminal.

___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users


Re: /etc/paths

2015-02-06 Thread Luc Bourhis

On 6 Feb 2015, at 19:21, Michael  wrote:

>> Shame on me! You are right. This is a new computer and /etc/paths did not
>> get copied from the old one as I thought. Sorry for the noise and thanks for
>> your patience!
> 
> /etc/paths? 
> This is the first I've seen any indication of this. Where is this documented?
> Is this the apple-approved way to add stuff to PATH for programs run by 
> launchD?

Not launchd, no. It's for the shell and it helps with MANPATH too. "man 
path_helper" for the details.



___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users


Re: Error: No valid Xcode installation is properly selected.

2012-08-29 Thread Luc Bourhis
Hi Ryan,

> sudo port -f selfupdate

thanks, it worked. I guess those installing from source are supposed to know 
what they are doing, which was not quite true in my case!

Thanks again,

Luc

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users


Re: Error: No valid Xcode installation is properly selected.

2012-08-28 Thread Luc Bourhis
Hi Clemens,

thanks for spending time on this. I looked into the code you quoted: on my 
computer _is_valid_developer_dir still checks for a subdirectory Headers inside 
$dir, which has the correct value /Applications/Xcode.app/Contents/Developer. 
That is precisely what the fix for #35150 should have removed. 

And indeed:

~> port version
Version: 2.1.99

Thus the upgrade to 2.1.2 failed and indeed:

~> sudo port -d selfupdate 
Password:
DEBUG: Copying /Users/luc/Library/Preferences/com.apple.dt.Xcode.plist to 
/opt/local/var/macports/home/Library/Preferences
DEBUG: MacPorts sources location: 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs
--->  Updating MacPorts base sources using rsync
receiving file list ... done

sent 36 bytes  received 69 bytes  42.00 bytes/sec
total size is 3543040  speedup is 33743.24
receiving file list ... done

sent 36 bytes  received 76 bytes  44.80 bytes/sec
total size is 512  speedup is 4.57
DEBUG: successful verification with key 
/opt/local/share/macports/macports-pubkey.pem
DEBUG: /usr/bin/tar -C 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/tmp -xf 
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base.tar
MacPorts base version 2.1.99 installed,
DEBUG: Rebuilding and reinstalling MacPorts if needed
MacPorts base version 2.1.2 downloaded.
--->  Updating the ports tree
Synchronizing local ports tree from file:///Users/luc/Developer/macports/dports
Creating port index in /Users/luc/Developer/macports/dports

Total number of ports parsed:   0 
Ports successfully parsed:  0 
Ports failed:   0 
Up-to-date ports skipped:   15604

--->  MacPorts base is probably trunk or a release candidate
DEBUG: Setting MacPorts sources ownership to root

The ports tree has been updated. To upgrade your installed ports, you should run
  port upgrade outdated

So it downloads 2.1.2 but it does not install it! What is it I am missing here?

Best wishes,

Luc

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users


Error: No valid Xcode installation is properly selected.

2012-08-28 Thread Luc Bourhis
Hi,

"install" or "upgrade" prints
{{{
Error:
Error: No valid Xcode installation is properly selected.
Error: Please use xcode-select to select an Xcode installation:
Error: sudo xcode-select -switch /Applications/Xcode.app # version
4.4.1
Error:
}}}
even after issuing that very xcode-select command. Then "port" seem to carry on 
with its business
in a successful manner. I am aware of #35150 and of the fix
that went into 2.1.2 but that is precisely the version I run. More info:
{{{
~> cc --version
Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix
}}}

Please CC me.

Best wishes,

Luc Bourhis

___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-users


Python 2.6.1 i386+x86_64 doesn't work with command arch?

2009-04-20 Thread Luc Bourhis

Hi,

I installed a universal i386 + x86_64 Python 2.6.1 as follow. Here is  
the relevant part of my macports.conf:


# Options for Universal Binaries (+universal variant)

# MACOSX_DEPLOYMENT_TARGET
universal_target10.5

# the SDK "sysroot" to use
universal_sysroot   /Developer/SDKs/MacOSX10.5.sdk

# machine architectures
universal_archs i386 x86_64

and my variants.conf features "+universal".


On my MacPro, the following
python -c 'import sys; print sys.maxint'
prints 9223372036854775807, proving that it ran in 64-bit mode. But then
arch -i386 python -c 'import sys; print sys.maxint'
prints the same number whereas the first command without arch run on  
my first gen MacBook Pro (32-bit) prints 2147483647, proving that it  
correctly runs in 32-bit mode. I compiled an universal snippet


#include 
#include 

int main() {
 std::cout << std::numeric_limits::max() << "\n";
 return 0;
}

It prints 9223372036854775807 and 2147483647 with and without arch - 
i386 respectively. So arch is not broken.


So clearly, arch does not manage to correctly run that python  
installed by MacPorts.


Would anybody have any insight into that issue?

Thanks in advance,

Luc Bourhis





smime.p7s
Description: S/MIME cryptographic signature
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users