port diagnose fails on 10.6.8
This is MacPorts 2.4.1 on a mac mini running 10.6.8. 'port diagnose fails like this: Error: process_cmd failed: Usage: xcode-select -print-path or: xcode-select -switch or: xcode-select -version Arguments: -print-path Prints the path of the current Xcode folder -switch Sets the path for the current Xcode folder -versionPrints xcode-select version information child process exited abnormally I am using XCode 3.2.6, the latest available fo 10.6.8. Apparently, the xcode-select call has changed somehow. Jan
all compilers blacklisted or unavailable
This is MacPorts 2.4.1 on MacOSX 10.6.8. A build of audio/sox starts with the following warning: $ sudo port install -d sox Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option ---> Computing dependencies for sox ---> Fetching archive for sox ---> Attempting to fetch sox-14.4.2_0.darwin_10.x86_64.tbz2 from https://packages.macports.org/sox ---> Attempting to fetch sox-14.4.2_0.darwin_10.x86_64.tbz2 from http://nue.de.packages.macports.org/sox ---> Attempting to fetch sox-14.4.2_0.darwin_10.x86_64.tbz2 from http://lil.fr.packages.macports.org/sox ---> Fetching distfiles for sox ---> Verifying checksums for sox ---> Extracting sox ---> Applying patches to sox ---> Configuring sox ---> Building sox ---> Staging sox into destroot ---> Installing sox @14.4.2_0 ---> Activating sox @14.4.2_0 ---> Cleaning sox ---> Updating database of binaries ---> Scanning binaries for linking errors ---> No broken files found. What "all compilers" are those? (I have Xcode 3.2.6) Why are they blacklisted? Who blacklisted them? Why are they unavailable? The gcc and clang from Xcode work just fine. How do I get port(1) to print all this for me if -d doesn't? WHy is the message printed twice? Jan
Re: Prevent MacPorts editing .bash_profile over and over again...
On Jan 28 16:31:12, ba...@barrys-emacs.org wrote: > I want to be able to stop MacPorts Installation from editing my .bash_profile. > As it happens I already set all the env var that are needed my self. On Feb 01 00:38:03, ryandes...@macports.org wrote: > > Nothing should change my .bash_profile without asking back. > > It is something that malware usually does. > > The MacPorts installer has always done this. I'm pretty sure it tells you it > will do this, and our documentation says so too. The alternative is that the > user installs MacPorts, then when they try to use it they get an error that > "port" could not be found in the path. The same error is there now. After a fresh install of 2.4.1 yesterday, 'port' is not found, because /opt/local/bin is not in my PATH. The installer has written the PATH=... bit into my ~/.profile, but that does not mean it is the PATH of the shell I am already running. It will be, after I start a new shell, or re-login. > this will cause tons of support requests that I would prefer to avoid, so I'd > like to keep things the way they are, with the installer modifying the user's > profile when needed. I appreciate you concern about being spammed with trivia. But it's one line in ~/.profile, which is equally trivial. I find mangling the user's shell configuration worse: someone who uses macports to install software is capable of editing one line in their config if told so. We can trade all this for a sentence that says "add /opt/local/bin to your $PATH". In fact, the documentation already says so for EDITOR. How is this different? On Feb 01 15:20:26, w...@bachsau.name wrote: > Not only repeated modifications. > It simply should not do that in any case. Exactly. I will try to come up with a diff tonight. Jan
Re: Prevent MacPorts editing .bash_profile over and over again...
On Mar 21, 2017, at 9:30 AM, Jan Stary wrote: > I appreciate you concern about being spammed with trivia. > But it's one line in ~/.profile, which is equally trivial. While I agree with you in principle (see list archives where I disagreed with adding this to the installer way back when it was first introduced) - Ryan is right that we used to get lots of support requests where people apparently weren't capable of reading the instructions and updating their $PATH themselves. Our actual experience around this issue tells us that it's worse to not try to set $PATH in the installer. > I find mangling the user's shell configuration worse: > someone who uses macports to install software > is capable of editing one line in their config if told so. users who are smart enough to edit their configs are also smart enough to install from source (where you don't have this issue at all). -- Daniel J. Luke
Re: Prevent MacPorts editing .bash_profile over and over again...
On Tue, Mar 21, 2017 at 11:29 AM, Daniel J. Luke wrote: > While I agree with you in principle (see list archives where I disagreed > with adding this to the installer way back when it was first introduced) - > Ryan is right that we used to get lots of support requests where people > apparently weren't capable of reading the instructions and updating their > $PATH themselves. Never assume people will read instructions. How often do we get people who cut and paste the boilerplate at the end of a failed build that tells them to check the build log, and mail it here asking what they should do? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: all compilers blacklisted or unavailable
On Tue, Mar 21, 2017 at 4:37 AM, Jan Stary wrote: > Why are they unavailable? The gcc and clang from Xcode work just fine. "Works for random stuff I tried it on" does not guarantee it doesn't throw spurious errors or even produce broken programs in specific cases (which is to say, most compilers have bugs, but you only run into them in certain cases). Compilers get blacklisted for specific ports when they have been found to be incapable of building that port properly. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: Prevent MacPorts editing .bash_profile over and over again...
Here is a diff to postflight and an accompanying diff to installing.xml
(what other places need to be touched if this goes through?)
Jan
diff --git a/portmgr/dmg/postflight.in b/portmgr/dmg/postflight.in
index 750553f0..a3a8bd80 100755
--- a/portmgr/dmg/postflight.in
+++ b/portmgr/dmg/postflight.in
@@ -87,28 +87,6 @@ function update_macports {
fi
}
-# Through this command we write an environment variable to an appropriate
shell configuration file,
-# backing up the original only if it exists and if it doesn't contain the
${OUR_STRING} identification string,
-# which hints that we've already tweaked it and therefore already backed it up.
-function write_setting () {
-if [[ -f "${HOME}/.${CONF_FILE}" ]] && ! grep "${OUR_BASESTRING}"
"${HOME}/.${CONF_FILE}" > /dev/null; then
-echo "Backing up your ${HOME}/.${CONF_FILE} shell confguration file as
${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX} before adapting it for MacPorts."
-/bin/cp -fp "${HOME}/.${CONF_FILE}"
"${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX}" || {
-echo "An attempt to backup your original configuration file
failed! Please set your MacPorts compatible environment manually."
-update_macports
-exit 1
-}
-echo -e "\n##\n# Your previous ${HOME}/.${CONF_FILE} file was backed
up as ${HOME}/.${CONF_FILE}.${BACKUP_SUFFIX}\n##" >> "${HOME}/.${CONF_FILE}"
-fi
-{
-echo -e "\n# ${OUR_STRING}: adding an appropriate ${1} variable for
use with MacPorts."
-echo "${ENV_COMMAND} ${1}${ASSIGN}${2}"
-echo -e "# Finished adapting your ${1} environment variable for use
with MacPorts.\n"
-} >> "${HOME}/.${CONF_FILE}"
-chown "${USER}" "${HOME}/.${CONF_FILE}" || echo "Warning: unable to adapt
permissions on your ${HOME}/.${CONF_FILE} shell configuration file!"
-echo "An appropriate ${1} variable has been added to your shell
environment by the MacPorts installer."
-}
-
function cleanup_man () {
# Remove old non-compressed man pages
echo -e "\nRemoving old man pages..."
@@ -195,8 +173,6 @@ function create_run_user {
fi
}
-echo "The MacPorts Project, postflight script version ${VERSION}: checking the
shell environment for user \"${USER}\"."
-
# create macports user
create_run_user
# Set up config files
@@ -207,78 +183,11 @@ cleanup_man
delete_old_tcl_package_link
delete_old_tcl_packages
-# Determine the user's shell, in order to choose an appropriate configuration
file we'll be tweaking.
-# Exit nicely if the shell is any other than bash or tcsh, as that's
considered non-standard.
-USHELL=$(${DSCL} . -read "/Users/${USER}" shell) || {
-echo "An attempt to determine your shell name failed! Please set your
MacPorts compatible environment manually."
-update_macports
-exit 1
-}
-# leave full path to shell
-USHELL=${USHELL#*shell: }
-
-case "${USHELL}" in
-*/tcsh)
-echo "Detected the tcsh shell."
-LOGIN_FLAG=""
-ENV_COMMAND="setenv"
-ASSIGN=" "
-if [[ -f "${HOME}/.tcshrc" ]]; then
-CONF_FILE=tcshrc
-elif [[ -f "${HOME}/.cshrc" ]]; then
-CONF_FILE=cshrc
-else
-CONF_FILE=tcshrc
-fi
-;;
-*/bash)
-echo "Detected the bash shell."
-LOGIN_FLAG="-l"
-ENV_COMMAND="export"
-ASSIGN="="
-if [[ -f "${HOME}/.bash_profile" ]]; then
-CONF_FILE=bash_profile
-elif [[ -f "${HOME}/.bash_login" ]]; then
-CONF_FILE=bash_login
-else
-CONF_FILE=profile
-fi
-;;
-*)
-echo "Unknown shell ($USHELL)! Please set your MacPorts compatible
environment manually."
-update_macports
-exit 0
-;;
-esac
-
-# Adding our setting to the PATH variable if not already there:
-# Run as the $USER: /usr/bin/su $USER -l
-# Run a command in the shell: -c "/usr/bin/printenv PATH"
-# Only process the last line output (profile may print info): tail -n 1
-# Output each path on its own line: tr ":" "\n"
-# Look for exactly the BINPATH: grep "^${BINPATH}$"
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv PATH" | tail -n 1 | tr ":"
"\n" | grep "^${BINPATH}$" > /dev/null; then
-echo "Your shell already has the right PATH environment variable for use
with MacPorts!"
-else
-write_setting PATH "\"${BINPATH}:${SBINPATH}:\$PATH\""
-fi
-
-# Adding our setting to the MANPATH variable only if it exists:
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv MANPATH" > /dev/null; then
-# check for MANPAGES already in MANPATH
-if /usr/bin/su "${USER}" -l -c "/usr/bin/printenv MANPATH" | tail -n 1 |
tr ":" "\n" | grep "^${MANPAGES}$" >/dev/null; then
-echo "Your shell already has the right MANPATH environment variable
for use with MacPorts!"
-else
-write_setting MANPATH "\"${MANPAGES}:\$MANPATH\""
-fi
-fi
-
-# Adding a DISPLAY variable only if we're running on Tiger or less and
Re: all compilers blacklisted or unavailable
On Mar 21 14:43:12, allber...@gmail.com wrote:
> On Tue, Mar 21, 2017 at 4:37 AM, Jan Stary wrote:
>
> > Why are they unavailable? The gcc and clang from Xcode work just fine.
>
>
> "Works for random stuff I tried it on" does not guarantee it doesn't throw
> spurious errors or even produce broken programs in specific cases (which is
> to say, most compilers have bugs, but you only run into them in certain
> cases). Compilers get blacklisted for specific ports when they have been
> found to be incapable of building that port properly.
I don't doubt that compilers throw errors or even produce broken code.
But which specific compilers are blacklisted for which specific reasons
when building sox, specifically? I don't see anything compiler-related
in the sox's Portfile.
Looking at the output of port -v -d install sox:
DEBUG: compiler clang 77 blacklisted because it matches {clang < 503}
DEBUG: compiler clang 77 blacklisted because it matches {clang < 500}
DEBUG: compiler clang 77 blacklisted because it matches {clang < 500}
Warning: All compilers are either blacklisted or unavailable; defaulting to
first fallback option
Warning: All compilers are either blacklisted or unavailable; defaulting to
first fallback option
That does not look like a specific reason why clang fails to build sox properly.
Does that mean clang < 500 (as installed by Xcode 3.2.6) is blacklisted as such,
for building any port?
Even if so, why are "all compilers blacklisted" after clang has been ruled out?
Jan
Re: all compilers blacklisted or unavailable
On Mar 21, 2017, at 5:03 PM, Jan Stary wrote:
> Looking at the output of port -v -d install sox:
>
> DEBUG: compiler clang 77 blacklisted because it matches {clang < 503}
> DEBUG: compiler clang 77 blacklisted because it matches {clang < 500}
> DEBUG: compiler clang 77 blacklisted because it matches {clang < 500}
> Warning: All compilers are either blacklisted or unavailable; defaulting to
> first fallback option
> Warning: All compilers are either blacklisted or unavailable; defaulting to
> first fallback option
>
> That does not look like a specific reason why clang fails to build sox
> properly.
you trimmed the relevant information - that's almost certainly coming from a
port that sox requires and not sox itself.
Most of the ports that use compiler blacklist have a comment in the portfile
explaining why (most people don't care, though ;-) ).
--
Daniel J. Luke
Re: all compilers blacklisted or unavailable
IIRC there's also an edge case when something tries to check the compiler
in a fetch step or w/e and the information doesn't exist yet, so all
compilers are "blacklisted" because there are no compilers defined yet,
while the code printing that assumes the compiler list is empty because
blacklisting removed all of them? And I think another if something tries to
look up Xcode-specific information but the xcode portgroup hasn't been
initialized?
On Tue, Mar 21, 2017 at 5:26 PM, Daniel J. Luke wrote:
> On Mar 21, 2017, at 5:03 PM, Jan Stary wrote:
> > Looking at the output of port -v -d install sox:
> >
> > DEBUG: compiler clang 77 blacklisted because it matches {clang < 503}
> > DEBUG: compiler clang 77 blacklisted because it matches {clang < 500}
> > DEBUG: compiler clang 77 blacklisted because it matches {clang < 500}
> > Warning: All compilers are either blacklisted or unavailable; defaulting
> to first fallback option
> > Warning: All compilers are either blacklisted or unavailable; defaulting
> to first fallback option
> >
> > That does not look like a specific reason why clang fails to build sox
> properly.
>
> you trimmed the relevant information - that's almost certainly coming from
> a port that sox requires and not sox itself.
>
> Most of the ports that use compiler blacklist have a comment in the
> portfile explaining why (most people don't care, though ;-) ).
>
> --
> Daniel J. Luke
>
>
>
>
--
brandon s allbery kf8nh sine nomine associates
allber...@gmail.com ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: Prevent MacPorts editing .bash_profile over and over again...
> On 21 Mar 2017, at 11:30 pm, Jan Stary wrote: > … > The same error is there now. > After a fresh install of 2.4.1 yesterday, > 'port' is not found, because /opt/local/bin is not in my PATH. > The installer has written the PATH=... bit into my ~/.profile, > but that does not mean it is the PATH of the shell I am already running. > It will be, after I start a new shell, or re-login. Does . ~/.profile work? -- Peter West p...@pbw.id.au “Even the pagans do as much, do they not?”
Re: Prevent MacPorts editing .bash_profile over and over again...
On Tue, 21 Mar 2017, Brandon Allbery wrote: > Never assume people will read instructions. How often do we get people > who cut and paste the boilerplate at the end of a failed build that > tells them to check the build log, and mail it here asking what they > should do? Which reminds me: would it be possible to symlink to the log file from somewhere in /tmp? It's a real PITA doing a C&P with a path that wraps lines... Yes, I'm an old fogey, and use 80 columns... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Re: Prevent MacPorts editing .bash_profile over and over again...
On Tue, Mar 21, 2017 at 5:23 PM, Dave Horsfall wrote: > On Tue, 21 Mar 2017, Brandon Allbery wrote: > > Never assume people will read instructions. How often do we get people > > who cut and paste the boilerplate at the end of a failed build that > > tells them to check the build log, and mail it here asking what they > > should do? > > Which reminds me: would it be possible to symlink to the log file from > somewhere in /tmp? It's a real PITA doing a C&P with a path that wraps > lines... Yes, I'm an old fogey, and use 80 columns... > vim $(port logfile thePort) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: Prevent MacPorts editing .bash_profile over and over again...
On Tue, Mar 21, 2017 at 7:18 PM, Brandon Allbery wrote: > vim $(port logfile thePort) > ...and the port you installed will usually get expanded with . (bash/zsh, in default emacs mode) so you don't even need to type that :) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: all compilers blacklisted or unavailable
On Mar 21 17:26:35, dl...@geeklair.net wrote:
> On Mar 21, 2017, at 5:03 PM, Jan Stary wrote:
> > Looking at the output of port -v -d install sox:
> >
> > DEBUG: compiler clang 77 blacklisted because it matches {clang < 503}
> > DEBUG: compiler clang 77 blacklisted because it matches {clang < 500}
> > DEBUG: compiler clang 77 blacklisted because it matches {clang < 500}
> > Warning: All compilers are either blacklisted or unavailable; defaulting to
> > first fallback option
> > Warning: All compilers are either blacklisted or unavailable; defaulting to
> > first fallback option
> >
> > That does not look like a specific reason why clang fails to build sox
> > properly.
>
> you trimmed the relevant information - that's almost certainly coming from a
> port that sox requires and not sox itself.
No, all of Sox's requirements are already installed.
> Most of the ports that use compiler blacklist have a comment in the portfile
> explaining why (most people don't care, though ;-) ).
SoX does not blacklist anything in its Portfile.
