Hot answers tagged macports
The suggestions you received cover what you're after: port clean --all all sudo port -f uninstall inactive If you can't wait for the clean one to run in the background, there are a few commands you can run manually and faster. Remove leftover build files (this is done automatically by default): sudo rm -rf /opt/local/var/macports/build/* Remove ...
bash-completion adds completion for: Command names after sudo and which Macports and Homebrew package names (optional) Hostnames in known_hosts for commands like ssh Folders on CDPATH And so on. You can print a list of completion commands with complete -p and see the source of a function with declare -f. Installing bash-completion with Homebrew $ brew ...
sudo port uninstall inactive This will remove your inactive ports.
If you want to uninstall all the old (non-active) versions try this: port -y -u uninstall # if you like what you see, change “port -y” to “sudo port” If you mean that you want to uninstall all the versions (non-active and active) of (e.g.) the postgresql83 port, then try this: port -y uninstall installed and postgresql83 # if you like what you see, ...
I used to use Macports because: It is generally more up to date Macports seems to be more common / popular Everyone else I work with uses it When I did my own research on this topic when I got my MBP last fall, Macports seemed to be most commonly recommended for reason #1 above, hence reason #2 (and probably reason #3). Compiling every package doesn't ...
It is probably a PATH issue. By default port is installed the directory /opt/local/bin. Add the path 'opt/local/bin' as an extra line to the plain text file /etc/paths and you should be good.
From the manual, uninstalling MacPorts works as follows. You need to first uninstall all ports: sudo port -fp uninstall --follow-dependents installed If port is not found, try /opt/local/bin/port instead. Also, to remove remainders of MacPorts, you will need to delete the following files by this single command (copy and paste it to Terminal): sudo rm ...
Most likely it is because bash has gcc hashed. Run $ hash to see which commands are hashed. If /usr/bin/gcc appears on the list, run $ hash gcc to rehash gcc. Afterwards you should see /opt/local/bin/gcc if you run hash, and running gcc should run the macports version – providing of course that you have selected it. /B2S Edit: For zsh users, run $ ...
I prefer homebrew due to its simplicity/speed -- my tools seem to be getting updated quickly at the moment. It's the most painless source based package management tool I've used and development seems quite active. What more could you want? (Yes, all the missing apps)
IMHO, the problem with Homebrew is it tries to use /usr/local in a way it was never meant to be used: owned by a user other than root. While I understand the homebrew developers take care not to munge with anything else in /usr/local, nothing else that installs to /usr/local will do the same for Homebrew. This can cause problems, and has for me... usually ...
You don't have to pick between the two. MacPorts installs software to /opt/local. Fink installs to /sw. Both leave the Darwin base system untouched, and the two can co-exist peacefully. Fink's binary packages are great, but they aren't always up-to-date. I tend to use Fink when they've got an up-to-date package, and I build from MacPorts if they don't. ...
I had the same problem. I did: sudo port deactivate -f subversion-perlbindings-5.12 which allows me to install the new version of the perl bindings.
Try hash -d python. This will tell bash to forget where it last saw the python executable.
They will not coexist well together. The Apple gcc looks in /usr/local for some things. This means that a macports compile could find something the porter did not expect. See macports mail lists and bugs for examples of things found in /usr/local.
I gave another answer on a similar question: Homebrew will cause problems when building software from source if it is installed in /usr/local. This is the default, which is a bad choice as this path is in the default search path of compilers and other tools. Therefore builds from other packaging software might pick up the wrong dependency, using ...
With slhck's help, I found the missing libfaac solution. I had to reinstall the ffmpeg macport with the following variant chosen to allow libfaac to install (which has been taken out of the standard package due to licensing issues) sudo port install ffmpeg +nonfree ...will install libfaac as well.
In the manpage of whereis, it clearly says (emphasis mine): The whereis utility checks the standard binary directories for the specified programs, printing out the paths of any it finds. The path searched is the string returned by the sysctl(8) utility for the ``user.cs_path'' string Contrary to that, which is the tool commonly used to check where ...
OSX has a built in command srm to securely remove files. See https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/srm.1.html. You can also use rm -P to overwrite the files with sequences of bytes three times.
I used to think that worries about what the Gnu build tools will make of /usr/local were verging on paranoid. The build tools expect there to be lots of things there: in the good old days before package managers (I joke), we compiled whatever to /usr/local. But while Autoconf usually does figure out issues, the sheer build complexity of many open-source ...
Many netstat features can be replaced with a lsof command. I was often using netstat -lnp | grep 1234 to find out who was listening on port 1234. With lsof (that is available on both systems), I can do: lsof -i :1234 The top command on OSX is not bad either, it's just different. And I'm quite sure some of the metrics only make sense on Mac.
The answer above didn't resolve the issue for me, but I found a similar easy solution with MacPorts: sudo port install curl-ca-bundle To install the Certificate Authrity bundle and then push its reference to the wget settings profile: echo CA_CERTIFICATE=/opt/local/share/curl/curl-ca-bundle.crt >> ~/.wgetrc
Mark Story has written a great article on how to achieve this. He is a CakePHP core developer, and uses this setup for work and cakephp development. http://mark-story.com/posts/view/maintaining-two-versions-of-php-with-macports
MacPorts Installer automatically modifies the environment so that MacPorts commands are called before system commands in its Postflight Script. You can type env in the terminal to see what your PATH is currently. If your ~/.profile was modified, you can manually change it back from: export PATH=/opt/local/bin:/opt/local/sbin:$PATH to export ...
Where are you looking for this source code? MacPorts downloads source packages and stores them in /opt/local/var/macports/distfiles. If you did port clean --all installed then your system should have gotten rid of these source pacakges. You may do better to run port clean --all all to get rid of source packages of software that you may have uninstalled. ...
coreutils in macports does not install GNU sed. GNU sed is installed by port gsed and will end up as /opt/local/bin/gsed
It looks like there are two problems going on. First, and this one's silly, you might not have accepted the XCode license agreement (See http://www.xensoft.com/?q=node/3). To solve this issue, just try: sudo xcodebuild -license # Press 'q' then type 'agree' to accept the license agreement Secondly, the version of MacPorts installed may still be verifying ...
Since I'm answering my own question, I was just going to delete it but others may find it useful in future. The solution is to brew uninstall postgresql then install it again. The reason it wasn't working was that the Macports install messed with some of the configs.
You can just remove it. /opt doesn't exist on a clean installation of OS X. If you want to completely uninstall MacPorts, you should anyway just have uninstalled the ports first. You can later install most applications again, through Homebrew, which also has OpenSSL. To remove all currently installed ports – which you probably can't do because you already ...
There is a solution/workaround for this: Update your version of reattach-to-user-namespace. This is used by tmux to execute programs. I use brew rather than macports, so I just did: brew update; brew upgrade reattach-to-user-namespace. Macports is likely to be able to do something similar. Add the following to your .tmux.conf file: set -g default-command ...
For test purposes, I'll use the octave port. List the distfiles required for the port by running port distfiles octave. You'll get the following output: ---> Distfiles for octave [octave-3.2.4.tar.gz] /opt/local/var/macports/distfiles/octave/octave-3.2.4.tar.gz md5: 90c39fa9e241ad2e978bcee4682a2ba9 sha1: 93b81fc300bc5e27e88b6668ef0622f29898dfd2 ...
Only top voted, non community-wiki answers of a minimum length are eligible