linux-kernel - Re: RFC: Fix for sphinx setup message

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: <20200222082324.42fb46b2@kernel.org>
Date:   Sat, 22 Feb 2020 08:23:24 +0100
From:   Mauro Carvalho Chehab <mchehab@...nel.org>
To:     "Bird, Tim" <Tim.Bird@...y.com>
Cc:     "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "corbet@....net" <corbet@....net>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Fix for sphinx setup message

Em Sat, 22 Feb 2020 08:16:44 +0100
Mauro Carvalho Chehab <mchehab@...nel.org> escreveu:

> Hi Tim,
> 
> Em Fri, 21 Feb 2020 22:15:36 +0000
> "Bird, Tim" <Tim.Bird@...y.com> escreveu:
> 
> > (Resend: Sorry for the dup.  I forgot to include the maintainers, and I had the LKML
> > address wrong.) 
> > 
> > I was trying to set up my machine to do some documentation work, 
> > and I had some problems with the sphinx install.  I figured out how to work
> > around the issue, but I have a question about how to add the information
> > to scripts/sphinx-pre-install (or whether it should go somewhere else).
> > 
> > Detailed messages below, but the TLl;DR is that I got the message:
> > -------
> > You should run:
> > 
> >     sudo apt-get install dvipng fonts-noto-cjk latexmk librsvg2-bin texlive-xetex
> >     /usr/bin/virtualenv sphinx_1.7.9
> >     . sphinx_1.7.9/bin/activate
> >     pip install -r ./Documentation/sphinx/requirements.txt
> >     ...
> > ------
> > 
> > The pip install step didn't work, and I found that I needed to have everything
> > based on python3 instead.  When I replaced:
> >     /usr/bin/virtualenv sphinx_1.7.9
> > with
> >     /usr/bin/virtualenv -p python3 sphinx_1.7.9
> > everything worked.
> > 
> > This message is coming from scripts/sphinx-pre-install (I believe on line 708).
> > 
> > Should I go ahead and submit a patch to add '-p python3' to that line?
> > 
> > Are there any downsides to enforcing that the virtualenv used for the
> > documentation build use python3 only?
> 
> Actually, the script tries to detect if python3 is installed. Currently, it
> does it by seeking for a python3 variant of virtualenv. If it finds, it
> changes the recommendation accordingly. The actual code with does that is
> this one:
> 
> 	my $virtualenv = findprog("virtualenv-3");
> 	$virtualenv = findprog("virtualenv-3.5") if (!$virtualenv);
> 	$virtualenv = findprog("virtualenv") if (!$virtualenv);
> 	$virtualenv = "virtualenv" if (!$virtualenv);
> 
> This works fine on older Fedora distros (and probably CentOS/RHEL), where
> there is a python3 variant of virtualenv. On Ubuntu (and Fedora 31), it
> will just use virtualenv.
> 
> So, perhaps if we add something like this (untested):
> 
> 	my $python = findprog("python3");
> 
> 	if ($python)
> 		$virtualenv = "$virtualenv -p $python";
> 
> it would make the trick. Please notice, however, that this could cause
> troubles with some distros that might have a version of virtualenv that
> won't work with the above. So, perhaps we should add something like the
> above inside give_debian_hints(), and either ensure that other Debian and 
> Ubuntu LTS versions will work with such change, or add some checks for the
> Ubuntu/Debian versions where we know this works.

Indeed it seems that, with some versions of python, virtualenv -p python3
don't work:

	https://stackoverflow.com/questions/23842713/using-python-3-in-virtualenv

This could well be something already solved on most distros, but I think it
would be safer if we only add "-p python3" if it is Ubuntu 16.04 or upper
(and doing a similar test for Debian).

> 
> Note: the version of the distribution (and its name) is already stored
> at the global var $system_release.
> 
> Cheers,
> Mauro




Cheers,
Mauro