On Wed, Oct 31, 2018, 7:41 AM Julian Andres Klode <
<email address hidden> wrote:
> So, you want to execute python in a subprocess and read its output?
>
> cosmic is also broken as documented in bug 1800823, as python is a
> symlink to python2.
>
> We probably should sanity check all of python, python2, python3.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1798872
>
> Title:
> _pythonSymlinkCheck fails to account for use of update-alternatives
>
> Status in ubuntu-release-upgrader package in Ubuntu:
> New
>
> Bug description:
> In order to deal with the fact that users often modify /usr/bin/python
> DistUpdgradeControler.py attempts to verify it is set to the correct
> version:
> ...
> fs_default_version = os.readlink('/usr/bin/python')
> except OSError as e:
> logging.error("os.readlink failed (%s)" % e)
> return False
> if not fs_default_version in (expected_default,
> os.path.join('/usr/bin', expected_default)):
> ...
>
> This check fails to account for setups using update-alternatives. In
> this case /usr/bin/python always points to another symlink ( i.e
> /etc/alternatives/python). This makes the above check always fail
> regardless of the python version actually running.
>
> sys.version_info should be used instead as it makes no assumptions
> about how python was invoked.
>
> "%s.%s.%s"
> %(sys.version_info[0],sys.version_info[1],sys.version_info[2])"%s.%s.%s"
> %(sys.version[0],sys.version_info[1],sys.version_info[2])
>
> Yields the version string (i.e '2.7.15') for the running python
> interpreter.
>
That would be one way. I was perposing the use of sys.version_info. This is
built-in python variable that tells what the currently running interpreter
version is regardless of how it was started. My understanding is that this
is intended as a compatibility check. In that case its the running python
version the should concern us.
On Wed, Oct 31, 2018, 7:41 AM Julian Andres Klode <
<email address hidden> wrote:
> So, you want to execute python in a subprocess and read its output? /bugs.launchpad .net/bugs/ 1798872 release- upgrader package in Ubuntu: troler. py attempts to verify it is set to the correct '/usr/bin/ python' ) error(" os.readlink failed (%s)" % e) join('/ usr/bin' , expected_default)): alternatives. In es/python) . This makes the above check always fail info[0] ,sys.version_ info[1] ,sys.version_ info[2] )"%s.%s. %s" 0],sys. version_ info[1] ,sys.version_ info[2] )
>
> cosmic is also broken as documented in bug 1800823, as python is a
> symlink to python2.
>
> We probably should sanity check all of python, python2, python3.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> _pythonSymlinkCheck fails to account for use of update-alternatives
>
> Status in ubuntu-
> New
>
> Bug description:
> In order to deal with the fact that users often modify /usr/bin/python
> DistUpdgradeCon
> version:
> ...
> fs_default_version = os.readlink(
> except OSError as e:
> logging.
> return False
> if not fs_default_version in (expected_default,
> os.path.
> ...
>
> This check fails to account for setups using update-
> this case /usr/bin/python always points to another symlink ( i.e
> /etc/alternativ
> regardless of the python version actually running.
>
> sys.version_info should be used instead as it makes no assumptions
> about how python was invoked.
>
> "%s.%s.%s"
> %(sys.version_
> %(sys.version[
>
> Yields the version string (i.e '2.7.15') for the running python
> interpreter.
>
That would be one way. I was perposing the use of sys.version_info. This is
built-in python variable that tells what the currently running interpreter
version is regardless of how it was started. My understanding is that this
is intended as a compatibility check. In that case its the running python
version the should concern us.
> /bugs.launchpad .net/ubuntu/ +source/ ubuntu- release- upgrader/ +bug/1798872/ +subscriptions
> To manage notifications about this bug go to:
>
> https:/
>