lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7f7c5d35-e644-4950-a3d3-dfcf46d5237e-mfwitten@gmail.com>
Date:	Sat, 09 Apr 2011 20:34:10 +0000
From:	Michael Witten <mfwitten@...il.com>
To:	Raghavendra D Prabhu <rprabhu@...hang.net>
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Use the environment variable PYTHON if defined

On Sun, 10 Apr 2011 00:12:45 +0530, Raghavendra D Prabhu wrote:

> I have a question regarding the message that is displayed.
> It says "No Python.h found" when variable PYTHON is not set
> correctly, it would be better if it said "No Python.h for
> Python 2.x found" since the header file supplied by Py3k is
> also Python.h and in the rare case of only Py3k installed on
> the box, it may be confusing.

Well...

If PYTHON or PYTHON_CONFIG don't point to an executable, then
there is a complaint about no executable being found.

If PYTHON (or, more specifically, PYTHON_CONFIG) points to the
Python *3* binary, then the message will be about Python 3 being
incompatible.

If PYTHON or PYTHON_CONFIG point to an executable that does not
provide a suitable `Python.h', then it says `No Python.h found'.

Thus, I think all of the cases are covered pretty well.
In particular, let's say that somebody triggers the third case,
but is confused because he does indeed have Python 3 with a valid
Python.h installed. That `No Python.h found' message will cause
him to look at how he configured PYTHON{,_CONFIG}, and he'll
see that he used the wrong executable (which is probably a
fairly unlikely scenario, anyway). Thus, he will configure the
right variable to point to the Python 3 executable, only to
get a message that Python 3 is incompatible. Thus, he will then
know that Python 2 is required.

I suppose, though, we could simplify the experience for the user
by giving a hint earlier on that Python 2 is required.

The patch that follows fulfills your request. My advice is to
save this email to /tmp/email and then apply it over the last
couple of patches like this:

  $ git apply /tmp/email
  $ git commit -a --amend -C HEAD

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 1fd46bf..b5276c7 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -522,7 +522,7 @@ else
       FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
 
       ifneq ($(call try-cc,$(SOURCE_PYTHON_EMBED),$(FLAGS_PYTHON_EMBED)),y)
-        $(call disable-python,Python.h)
+        $(call disable-python,Python.h (for Python 2.x))
       else
 
         ifneq ($(call try-cc,$(SOURCE_PYTHON_VERSION),$(FLAGS_PYTHON_EMBED)),y)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ