On Tue, Jul 22, 2014 at 2:28 AM, Joshua Root j...@macports.org wrote:
On 2014-7-22 10:08 , Adam Dershowitz wrote:
A few ideas:
Checking for files that should not be in macports directory, that end up
being there. They could be left either by an old install, or by a
different installer
Hey Ryan,
On 7/22/14, 8:48 PM, Ryan Schmidt wrote:
If you don't already do this, it would be useful to check that:
* Xcode is installed
* the Xcode version is new enough to be supported by the OS X version (some
users upgrade the OS and forget to upgrade Xcode)
* the Xcode version is not
On 2014-7-22 10:08 , Adam Dershowitz wrote:
A few ideas:
Checking for files that should not be in macports directory, that end up
being there. They could be left either by an old install, or by a different
installer that inappropriately put them in the directory (there was some
recent
On 2014-7-22 07:33 , Kyle Sammons wrote:
Hey everyone,
I've been working on a command, port doctor that checks for common
issues in the user's environment. I've implemented just about everything
I, Michael D, Snc, and Neverpanic can think of, so I was wondering if
you guys had anything else
Hello,
A few ideas if they haven't been mentioned:
- Check all local sources (sources.conf)
- If there are Portfiles in sub-folder, if PortIndex exists
- If the system port has a newer version
- Any duplicate ports in multiple local sources
- Multiple $PATH entries in shell startup
On Tue, Jul 22, 2014 at 2:47 AM, Joshua Root j...@macports.org wrote:
There are some more unusual ways that people manage to break their
systems, like replacing executables (sed, tar, etc...) in /usr/bin with
incompatible versions (or just deleting them). I'm not sure if you want
to go down
On Tue, Jul 22, 2014 at 2:28 AM, Joshua Root j...@macports.org wrote:
On 2014-7-22 10:08 , Adam Dershowitz wrote:
Checking for files that should not be in macports directory, that end up
being there. They could be left either by an old install, or by a different
installer that
Hey Joshua,
On 7/21/14, 11:47 PM, Joshua Root wrote
If you're going to check these, you might as well check for sqlite and
openssl too. We also need the system's tclsh for building from source,
which includes selfupdate.
Done.
I assume you're using the $prefix variable here, not hardcoding
On Tue, Jul 22, 2014 at 2:01 PM, Kyle Sammons ksamm...@macports.org wrote:
There are some more unusual ways that people manage to break their
systems, like replacing executables (sed, tar, etc...) in /usr/bin with
incompatible versions (or just deleting them). I'm not sure if you want
to go
Quick and probably stupid question here.
* On 21.07.2014 11:33 pm, Kyle Sammons wrote:
- Dylibs in /usr/local/lib
- Header files in /usr/local/include
Will `doctor` error if something like this is being found? Some software likes
to install headers and dylibs to those locations and MacPorts
On Tue, Jul 22, 2014 at 8:23 PM, Mihai Moldovan io...@ionic.de wrote:
Will `doctor` error if something like this is being found? Some software
likes
to install headers and dylibs to those locations and MacPorts should in
theory
not be affected when using -(i)sysroot.
In theory. Practice
On Jul 21, 2014, at 4:33 PM, Kyle Sammons wrote:
I've been working on a command, port doctor that checks for common issues
in the user's environment. I've implemented just about everything I, Michael
D, Snc, and Neverpanic can think of, so I was wondering if you guys had
anything else
Hey everyone,
I've been working on a command, port doctor that checks for common issues
in the user's environment. I've implemented just about everything I,
Michael D, Snc, and Neverpanic can think of, so I was wondering if you guys
had anything else you'd like to see check by doctor. Currently,
A few ideas:
Checking for files that should not be in macports directory, that end up being
there. They could be left either by an old install, or by a different
installer that inappropriately put them in the directory (there was some recent
discussion of an installer for an application that
14 matches
Mail list logo
