On Fri, Dec 13, 2019 at 05:30:59AM +0000, Ken Moffat via blfs-dev wrote:
> I'm trying to test things to see what can use python3 instead of
> python2, now that python2 is about to go End Of Life.
>
> In my normal desktop builds I need polkit - ISTR that was for
> usermode Xorg. But polkit required JS-60.
>
> Initially that fails with 'python not found'.
>
> The configure script, which is what invokes python, contains:
>
> which python2.7 > /dev/null && exec python2.7 "$TOPSRCDIR/configure.py" "$@"
> || exec python "$TOPSRCDIR/configure.py" "$@"
>
> so I started with a sed 's/ python / python3 /' but that then
> failed:
>
> Traceback (most recent call last):
> File "../js/src/../../configure.py", line 16, in <module>
> from mozbuild.configure import ConfigureSandbox
> File
> "/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
> line 7, in <module>
> import __builtin__
> ModuleNotFoundError: No module named '__builtin__'
>
> so I tried adding:
>
> 2to3 -w js/src/configure but that then failed:
>
> RefactoringTool: Skipping optional fixer: buffer
> RefactoringTool: Skipping optional fixer: idioms
> RefactoringTool: Skipping optional fixer: set_literal
> RefactoringTool: Skipping optional fixer: ws_comma
> RefactoringTool: Can't parse js/src/configure: ParseError: bad input:
> type=11, value=':', context=('#!/bin/sh\n# This Source Code Form is subject
> to the terms of the Mozilla Public\n# License, v. 2.0. If a copy of the MPL
> was not distributed with this\n# file, You can obtain one at
> http://mozilla.org/MPL/2.0/.\n#\n# Welcome to the new world of configure.
> We\'re working on moving to a\n# python3 based configure. In the meanwhile,
> remains of the old autoconf\n# based configure is in old-configure.in.\n# If
> you need to add something, please come talk to the build system\n# peers for
> now.\n#\n# Because adding a configure file in the tree is going to conflict
> with\n# existing configure files in people\'s (and automation) work trees,
> and\n# because some automation jobs are still running autoconf and
> configure\n# "manually", this file is actually an m4 file that is processed
> by\n# autoconf, but doesn\'t call any autoconf macros. The `divert` line\n#
> below ensures the script that follows is output by autoconf.\n', (18, 0))
> RefactoringTool: No files need to be modified.
> RefactoringTool: There was 1 error:
> RefactoringTool: Can't parse js/src/configure: ParseError: bad input:
> type=11, value=':', context=('#!/bin/sh\n# This Source Code Form is subject
> to the terms of the Mozilla Public\n# License, v. 2.0. If a copy of the MPL
> was not distributed with this\n# file, You can obtain one at
> http://mozilla.org/MPL/2.0/.\n#\n# Welcome to the new world of configure.
> We\'re working on moving to a\n# python3 based configure. In the meanwhile,
> remains of the old autoconf\n# based configure is in old-configure.in.\n# If
> you need to add something, please come talk to the build system\n# peers for
> now.\n#\n# Because adding a configure file in the tree is going to conflict
> with\n# existing configure files in people\'s (and automation) work trees,
> and\n# because some automation jobs are still running autoconf and
> configure\n# "manually", this file is actually an m4 file that is processed
> by\n# autoconf, but doesn\'t call any autoconf macros. The `divert` line\n#
> below ensures the script that follows is output by autoconf.\n', (18, 0))
>
> I then followed that with '||' to allow for failure status. But
> somewhere it is still trying to invoke python, because immediately
> after that crap about not parsing the configure file it gives me:
>
> ../js/src/configure: line 27: exec: python: not found
> Traceback (most recent call last):
> File "../js/src/../../configure.py", line 16, in <module>
> from mozbuild.configure import ConfigureSandbox
> File
> "/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
> line 7, in <module>
> import __builtin__
> ModuleNotFoundError: No module named '__builtin__'
> Traceback (most recent call last):
> File "../js/src/../../configure.py", line 16, in <module>
> from mozbuild.configure import ConfigureSandbox
> File
> "/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
> line 7, in <module>
> import __builtin__
> ModuleNotFoundError: No module named '__builtin__'
> Traceback (most recent call last):
> File "../js/src/../../configure.py", line 16, in <module>
> from mozbuild.configure import ConfigureSandbox
> File
> "/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
> line 7, in <module>
> import __builtin__
> ModuleNotFoundError: No module named '__builtin__'
>
I then tried changing all of the mozilla python scripts which start
with #!/usr/bin/env python, and the (one, I think) which invokes
/usr/bin/python, to use python3 but something still tried to invoke
python and halted. Forgot to mention that, but it explains why I'm
now thinking about symlinking python to python3.
> Hmm, I see that fedora have a mozjs68-68.3.0.1-fc32.src.rpm - I
> suppose I'll have to take a look at that, although since I think
> fedora install python3 as just python, I'm not overly hopeful - a
> quick look shows it untars firefox-68.3.0, adds some patches,
> rmeoves some bundled security libs (nss, nspr I guess) and then
> proceeds.
>
> There is an issue for spidermonkey68 at gnome:
> https://gitlab.gnome.org/GNOME/gjs/issues/270 which is apparently
> waiting for 68.4.0 before it is ready. Whether or not that will
> help with building against python3 is a different question, to which
> I have no answer (the missing __builtin__ suggests it might not).
>
> Going forward, perhaps we need to install python3 as both python3
> and python, and find a way to stop python2, if it is installed,
> installing as python ?
>
> Maybe as simple as:
>
> 1. in LFS ln -sv python3 /usr/bin/python
>
> 2. in BLFS, if installign python2 :
> rm /usr/bin/python
> ln -sv python3 /usr/bin/python
>
> ??
>
> Yes, I know that upstream python has claimed that python should
> still be python2, but I think we're fast going to reach the point
> where that causes more trouble than it is worth.
>
> For the moment, I'm giving up on this slithering mess.
>
> Maybe I'll try creating the python symlink, or maybe it would be
> easier to just start banging my head agaisnt a brick wall.
>
> ĸen
> --
> We've all got both light and dark inside of us.
> What matters is the part we choose to act on.
> -- Sirius Black
> --
> http://lists.linuxfromscratch.org/listinfo/blfs-dev
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
--
We've all got both light and dark inside of us.
What matters is the part we choose to act on.
-- Sirius Black
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
