Re: [blfs-dev] Testing without python2 : dead halt at JS60.

2019-12-12 Thread Ken Moffat via blfs-dev 
On Fri, Dec 13, 2019 at 05:30:59AM +, 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 
> from mozbuild.configure import ConfigureSandbox
>   File 
> "/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
>  line 7, in 
> 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 
> from mozbuild.configure import ConfigureSandbox
>   File
> "/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
> line 7, in 
> import __builtin__
> ModuleNotFoundError: No module named '__builtin__'
> Traceback (most recent call last):
>   File "../js/src/../../configure.py", line 16, in 
> from mozbuild.configure import ConfigureSandbox
>   File
> "/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
> line 7, in 
> import __builtin__
> ModuleNotFoundError: No module named '__builtin__'
> Traceback (most recent call last):
>   File "../js/src/../../configure.py", line 16, in 
> from mozbuild.configure import ConfigureSandbox
>   File
> "/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
> line 7, in 
> 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

[blfs-dev] Testing without python2 : dead halt at JS60.

2019-12-12 Thread Ken Moffat via blfs-dev 
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 
from mozbuild.configure import ConfigureSandbox
  File 
"/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py", 
line 7, in 
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 
from mozbuild.configure import ConfigureSandbox
  File
"/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
line 7, in 
import __builtin__
ModuleNotFoundError: No module named '__builtin__'
Traceback (most recent call last):
  File "../js/src/../../configure.py", line 16, in 
from mozbuild.configure import ConfigureSandbox
  File
"/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
line 7, in 
import __builtin__
ModuleNotFoundError: No module named '__builtin__'
Traceback (most recent call last):
  File "../js/src/../../configure.py", line 16, in 
from mozbuild.configure import ConfigureSandbox
  File
"/scratch/working/mozjs-60.8.0/python/mozbuild/mozbuild/configure/__init__.py",
line 7, in 
import __builtin__
ModuleNotFoundError: No module named '__builtin__'

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

[blfs-dev] Possible problem in iptables-1.8.4.

2019-12-12 Thread Ken Moffat via blfs-dev 
After my previous duff report on lfs a little while ago, I'm
hesitant to report this, but I think that libiptc no longer gets
installed, i.e .libip4tc and libip6tc seem to have replaced it.

If so, the command starting

for file in ip4tc ip6tc ipq iptc xtables

needs to drop the iptc.

ĸ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

Re: [blfs-dev] More breakage from ICU-65.1 U16_NEXT requiring semilong

2019-12-12 Thread Pierre Labastie via blfs-dev 
Le 03/12/2019 à 13:02, Ken Moffat via blfs-dev a écrit :
> After happening upon the problem in libfreehand (for libreoffice)
> where one line in the file had a U16_NEXT( ... )
> without a terminating semicolon I've hit the same thing in the
> chromium part of qtwebengine-5.13.2.
> 
> The initial error messages point to the _next_ line, in this case
> ./../../../../src/3rdparty/chromium/third_party/blink/renderer/core/dom/document.cc:5714:5:
>  error: expected ';' before 'if'
>  5714 | if (c == ':') {
>   | ^~
> 
> and line 5713 again uses U16_NEXT.  Fortunately, this time we have
> the source when we start to build.  Normally I dislike seds which
> address a line number by it's number, but in this case I think it's
> appropriate:
> 
> sed -i '5713s/.*/&;/' \
>   src/3rdparty/chromium/third_party/blink/renderer/core/dom/document.cc
> 
> Will address it in a mo.
> 

I've hit this in webkitgtk-2.26.2. There are four places with a missing 
semicolon,
and a lot of other places with a semicolon... Furthermore they have
an internal copy of icu. I could get it to build with the following:

grep -rl --exclude-dir icu 'U16_NEXT.*[^;]$' |
  xargs sed -i 's/U16_NEXT.*[^;]$/&;/'

Pierre
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page