Hi Markus,
Le jeu. 8 nov. 2018 09:46, Markus Armbruster <arm...@redhat.com> a écrit : > Cleber Rosa <cr...@redhat.com> writes: > > > On 11/7/18 1:05 AM, Markus Armbruster wrote: > >> Eduardo Habkost <ehabk...@redhat.com> writes: > >> > >>> The $(SHELLSTATUS) variable requires GNU make >= 4.2, but Travis > >>> seems to provide an older version. Change the existing rules to > >>> use command output instead of exit code, to make it compatible > >>> with older GNU make versions. > >>> > >>> Signed-off-by: Eduardo Habkost <ehabk...@redhat.com> > >>> --- > >>> I think that's the cause of the Travis failures. I have > >>> submitted a test job right now, at: > >>> https://travis-ci.org/ehabkost/qemu-hacks/jobs/451387962 > >>> Let's see if it fixes the issue. > >>> --- > >>> tests/Makefile.include | 4 ++-- > >>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/tests/Makefile.include b/tests/Makefile.include > >>> index d2e577eabb..074eece558 100644 > >>> --- a/tests/Makefile.include > >>> +++ b/tests/Makefile.include > >>> @@ -913,8 +913,8 @@ TESTS_RESULTS_DIR=$(BUILD_DIR)/tests/results > >>> # information please refer to "avocado --help". > >>> AVOCADO_SHOW=none > >>> > >>> -$(shell $(PYTHON) -c 'import sys; assert sys.version_info >= (3,0)' > >/dev/null 2>&1) > >>> -ifeq ($(.SHELLSTATUS),0) > >>> +PYTHON3 = $(shell $(PYTHON) -c 'import sys; print(1 if > sys.version_info >= (3, 0) else 0)') > >>> +ifeq ($(PYTHON3), 1) > >>> $(TESTS_VENV_DIR): $(TESTS_VENV_REQ) > >>> $(call quiet-command, \ > >>> $(PYTHON) -m venv --system-site-packages $@, \ > >> > >> PEP 394 recommends software distributions install Python 3 into the > >> default path as python3, and users use that instead of python, except > >> for programs that are source compatible with both 2 and 3. So, is > >> finding out whether python is a Python 3 really appropriate? Why can't > >> we just use python3 and be done with it? > >> > > > > I mentioned that before, when you pointed out the issue you fix here, > > that configure may be the best place to get the Python version (not only > > the major version) and make it available elsewhere. Even if not used > > for other purposes, it is IMO important information to show on the > > resulting "configure" output. > > > > I'm sending patches to do that in a few. > > > >> If we can't: isn't this a configure problem? > >> > > > > I believe adhering to PEP394 is a good thing, but even that document > > recognizes that the real world is not a perfect place: "however, end > > users should be aware that python refers to python3 on at least Arch > > Linux". And it only covers *nix systems, so if we hope to care for > > non-*nix systems, we have to check the Python version manually. > > > > So, I guess the safest approach from QEMU's side is to check for the > > version indeed. > > If somebody can point to a system people still use where python3 doesn't > get you a Python 3, but python does, catering for such (crappy) systems > in configure makes sense. Until then, it's a waste of brain waves and > configure run time. > > PEP 394 mentions Arch Linux. It's been seven years. What's the most > recent version of Arch Linux that's still crappy in this regard? > Arch doesn't provide python2 by default, thus python points to python3. I think what's crappy is scripts expecting python to be python2. >