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

2019-12-22 Thread DJ Lucas via blfs-dev



On 12/22/2019 4:20 AM, DJ Lucas via blfs-dev wrote:


It's trying to use 2.7 with 3.x syntax. `sed 's@2\.7@3.8@g' -i 
../js/src/configure` will get us past that. It builds to completion, 
and installs to DESTDIR, but I haven't used it yet.


I didn't look at it, it doesn't install any python modules, just for the 
build system, so seems to be fine.


--DJ

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


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

2019-12-22 Thread DJ Lucas via blfs-dev



On 12/21/2019 11:35 AM, Xi Ruoyao via blfs-dev wrote:

On 2019-12-16 00:53 +, Ken Moffat via blfs-dev wrote:

Indeed.  The "patch" I found was 9800 lines.  I haven't counted how
many lines are in my first attempt to update it.  I have a severe
dislike of python, as is probably already apparent (the whitespace
issue) and I mostly find the error messages unuseful - if it fails
to find a specific thing, I would hope to get a more-specific
message.

I uploaded a mozjs-60 tarball which can be built with /usr/bin/python ->
python3:

http://www.linuxfromscratch.org/~xry111/mozjs-60.8.0-py3-src.tar.xz

“Patching" won't work here.  Inside the source code tree there is a file n
amed pip-8.1.2-py2.py3-none-any.whl.  It's actually a zip file containing some
python code.  One .py file in the whl file have to be updated.  "Patching" can't
modify a zip file.

So...I started down this path on my most recent build.

I started with the (apparently incorrect) assumption that Mozilla 
projects will require Python-2.7.
I have /usr/bin/python -> python3.8, /usr/bin/python-config -> 
python3.8-config, and /usr/bin/pip -> pip3.8.


I did the following with the original source (which worked for dependents):
===
# Fix incorrect interpreters
for file in `grep -Rl "#\!/usr/bin/env python" *`
do
 sed 's@/usr/bin/env python@/usr/bin/env python2@' -i $file
done
# Undo damage from fist step
for file in `grep -Rl "/usr/bin/env python23" *`
do
    sed 's@python23@python3@g' -i $file
done
===



Using your tarball with the above setup, I get an error:

dj@lfsdt1 [ /sources/mozjs-60.8.0-py3-src/mozjs-build ]$ 
../js/src/configure --prefix=/usr --with-intl-api --with-system-zlib 
--with-system-icu --disable-jemalloc  
--enable-readline && make  File 
"../js/src/../../configure.py", line 66

    print("Creating config.status", file=sys.stderr)
    ^
SyntaxError: invalid syntax


It's trying to use 2.7 with 3.x syntax. `sed 's@2\.7@3.8@g' -i 
../js/src/configure` will get us past that. It builds to completion, and 
installs to DESTDIR, but I haven't used it yet.


--DJ

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


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

2019-12-21 Thread Xi Ruoyao via blfs-dev
On 2019-12-16 00:53 +, Ken Moffat via blfs-dev wrote:
> Indeed.  The "patch" I found was 9800 lines.  I haven't counted how
> many lines are in my first attempt to update it.  I have a severe
> dislike of python, as is probably already apparent (the whitespace
> issue) and I mostly find the error messages unuseful - if it fails
> to find a specific thing, I would hope to get a more-specific
> message.

I uploaded a mozjs-60 tarball which can be built with /usr/bin/python ->
python3:

http://www.linuxfromscratch.org/~xry111/mozjs-60.8.0-py3-src.tar.xz

“Patching" won't work here.  Inside the source code tree there is a file n
amed pip-8.1.2-py2.py3-none-any.whl.  It's actually a zip file containing some
python code.  One .py file in the whl file have to be updated.  "Patching" can't
modify a zip file.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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


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

2019-12-15 Thread Ken Moffat via blfs-dev
On Sun, Dec 15, 2019 at 04:08:09PM +, DJ Lucas via blfs-dev wrote:
> On December 15, 2019 8:14:20 AM CST, Ken Moffat via blfs-dev 
>  wrote:
> >On Fri, Dec 13, 2019 at 08:57:09AM +, DJ Lucas via blfs-dev wrote:
> >> On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev
> 
> I'm sorry, I didn't mean to suggest that we can completely scrub it just yet. 
> Mozilla specifically, has a lot of work to do yet. We could go 
> python->python3 at this point, but it requires changes in the remaining 
> python2 packages.
> 
> --DJ
> 
I didn't read your post as suggesting that we could scrub it, I was
hoping to find out what needs it (and of course, some of those
things are critical to other packages).  I just hadn't expected to
steam into the buffers before X was in place.

Hmm, maybe I could look at building suid X for this exercise, if I
can persuade myself to go back to it.

ĸ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] Testing without python2 : dead halt at JS60.

2019-12-15 Thread Ken Moffat via blfs-dev
On Sun, Dec 15, 2019 at 11:35:31AM -0600, Bruce Dubbs via blfs-dev wrote:
> On 12/15/19 10:16 AM, DJ Lucas via blfs-dev wrote:
> > On December 15, 2019 8:14:20 AM CST, Ken Moffat via blfs-dev 
> >  wrote:
> > > On Fri, Dec 13, 2019 at 08:57:09AM +, DJ Lucas via blfs-dev wrote:
> > > > On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev
> > >  wrote:
> > > > 
> > > But when I gave it a first go, with python symlinked to python3, the
> > > configure immediately failed:
> > > 
> > > ken@plexi /tmp/mozjs-60.8.0/mozjs-build $../js/src/configure
> > > --prefix=/usr   \
> > > >  --with-intl-api \
> > > >  --with-system-zlib  \
> > > >  --with-system-icu   \
> > > >  --disable-jemalloc  \
> > > >  --enable-readline
> > >   File "../js/src/../../configure.py", line 65
> > > print("Creating config.status", file=sys.stderr)
> > 
> > Sorry, I missed this. Yes this is python3 syntax so something is calling 
> > python2 explicitly.
> 

To DJ - thanks for confirming.  The problem is always finding where
it got called explicitly.  Maybe I'll take another look to see if I
can find remaining python2 references.

> A quick check finds 93 files in mozjs-60.8.0 referencing python2.  Some
> instances:
> 
> python/mozboot/mozboot/base.py:
>   MODERN_PYTHON_VERSION = LooseVersion('2.7.3')
> 

I think that is the minimum.  The items below are possibles.

> python/mozboot/mozboot/archlinux.py:
> SYSTEM_PACKAGES = [
> 'autoconf2.13',
> ...
> 'python2',
> 'python2-setuptools',
> ...
> 
> js/src/devtools/rootAnalysis/analyze.py:
>   ((os.environ.get('PYTHON', 'python2.7'),
> 
> It looks like mozjs needs a major overhaul to eliminate python2.
> 
>   -- Bruce

Indeed.  The "patch" I found was 9800 lines.  I haven't counted how
many lines are in my first attempt to update it.  I have a severe
dislike of python, as is probably already apparent (the whitespace
issue) and I mostly find the error messages unuseful - if it fails
to find a specific thing, I would hope to get a more-specific
message.

ĸen
> -- 
> 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


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

2019-12-15 Thread Bruce Dubbs via blfs-dev

On 12/15/19 10:16 AM, DJ Lucas via blfs-dev wrote:

On December 15, 2019 8:14:20 AM CST, Ken Moffat via blfs-dev 
 wrote:

On Fri, Dec 13, 2019 at 08:57:09AM +, DJ Lucas via blfs-dev wrote:

On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev

 wrote:




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.


That's not exactly correct. We are at the point where the majority

use python3. We need to get rid of python2 build instructions for
remaining modules that are not dependencies for something else using
python2, sed/patch the remaining packages to explicitly use
'/usr/bin/python2' or '/usr/bin/env python2' and then we are compliant
with the PEP (84 IIRC) with a python->python3 symlink. The big thing is
the "majority" of packages, though it was worded differently IIRC. Arch
can really help here.




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.



--DJ


So, I looked at Arch and they are still using python2 for JS60.

Fedora's build uses raw firefoxi68, I'm reluctant to try that.
As I said in my original post: There is an issue for
spidermonkey68 at gnome:
  https://gitlab.gnome.org/GNOME/gjs/issues/270 which is
apparently waiting for firefox 68.4.0 before it is ready.  That
version of firefox should be released at the start of January.

I suspect that when the new spidermonkey appears it _will_ need
the python -> python3 symlink.

In the meantime I found a patch at
https://code.foxkit.us/adelie/packages/blob/f2b5773da19ab397fbe64fd32dacc383cfe4cd77/user/mozjs/python3.patch
from Adelie linux, originally against 52.4.  A very strange patch, I
could not get it to apply at all, so in the end I've spent some time
manually running seds for some obvious things (e.g. remove from
__future__) and then attempting to manually apply the other changes.
Of course, some of the code has changed, and I'm sure not everything
is right.

What is most odd about the patch is that the first part has (original)
and (refactored) marks for old and new files, but much later many
other more conventional diffs have been appended, often several for
the same file.

But when I gave it a first go, with python symlinked to python3, the
configure immediately failed:

ken@plexi /tmp/mozjs-60.8.0/mozjs-build $../js/src/configure
--prefix=/usr   \

 --with-intl-api \
 --with-system-zlib  \
 --with-system-icu   \
 --disable-jemalloc  \
 --enable-readline

  File "../js/src/../../configure.py", line 65
print("Creating config.status", file=sys.stderr)


Sorry, I missed this. Yes this is python3 syntax so something is calling 
python2 explicitly.


A quick check finds 93 files in mozjs-60.8.0 referencing python2.  Some 
instances:


python/mozboot/mozboot/base.py:
  MODERN_PYTHON_VERSION = LooseVersion('2.7.3')

python/mozboot/mozboot/archlinux.py:
SYSTEM_PACKAGES = [
'autoconf2.13',
...
'python2',
'python2-setuptools',
...

js/src/devtools/rootAnalysis/analyze.py:
  ((os.environ.get('PYTHON', 'python2.7'),

It looks like mozjs needs a major overhaul to eliminate python2.

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


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

2019-12-15 Thread DJ Lucas via blfs-dev
On December 15, 2019 8:14:20 AM CST, Ken Moffat via blfs-dev 
 wrote:
>On Fri, Dec 13, 2019 at 08:57:09AM +, DJ Lucas via blfs-dev wrote:
>> On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev
> wrote:
>> 
>> >
>> >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.
>> 
>> That's not exactly correct. We are at the point where the majority
>use python3. We need to get rid of python2 build instructions for
>remaining modules that are not dependencies for something else using
>python2, sed/patch the remaining packages to explicitly use
>'/usr/bin/python2' or '/usr/bin/env python2' and then we are compliant
>with the PEP (84 IIRC) with a python->python3 symlink. The big thing is
>the "majority" of packages, though it was worded differently IIRC. Arch
>can really help here.
>> 
>> >
>> >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.
>> >
>> 
>> --DJ
>> 
>So, I looked at Arch and they are still using python2 for JS60.
>
>Fedora's build uses raw firefoxi68, I'm reluctant to try that.
>As I said in my original post: There is an issue for
>spidermonkey68 at gnome:
>  https://gitlab.gnome.org/GNOME/gjs/issues/270 which is
>apparently waiting for firefox 68.4.0 before it is ready.  That
>version of firefox should be released at the start of January.
>
>I suspect that when the new spidermonkey appears it _will_ need
>the python -> python3 symlink.
>
>In the meantime I found a patch at
>https://code.foxkit.us/adelie/packages/blob/f2b5773da19ab397fbe64fd32dacc383cfe4cd77/user/mozjs/python3.patch
>from Adelie linux, originally against 52.4.  A very strange patch, I
>could not get it to apply at all, so in the end I've spent some time
>manually running seds for some obvious things (e.g. remove from
>__future__) and then attempting to manually apply the other changes.
>Of course, some of the code has changed, and I'm sure not everything
>is right.
>
>What is most odd about the patch is that the first part has (original)
>and (refactored) marks for old and new files, but much later many
>other more conventional diffs have been appended, often several for
>the same file.
>
>But when I gave it a first go, with python symlinked to python3, the
>configure immediately failed:
>
>ken@plexi /tmp/mozjs-60.8.0/mozjs-build $../js/src/configure
>--prefix=/usr   \
>> --with-intl-api \
>> --with-system-zlib  \
>> --with-system-icu   \
>> --disable-jemalloc  \
>> --enable-readline
>  File "../js/src/../../configure.py", line 65
>print("Creating config.status", file=sys.stderr)
>^
>SyntaxError: invalid syntax
>
>A quick look at https://docs.python.org/3/whatsnew/3.0.html suggests
>that the syntax is correct.  So I'm giving up on this attempt to
>find out which parts of my normal desktop still need python2.
>

I'm sorry, I didn't mean to suggest that we can completely scrub it just yet. 
Mozilla specifically, has a lot of work to do yet. We could go python->python3 
at this point, but it requires changes in the remaining python2 packages.

--DJ


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


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

2019-12-15 Thread DJ Lucas via blfs-dev
On December 15, 2019 8:14:20 AM CST, Ken Moffat via blfs-dev 
 wrote:
>On Fri, Dec 13, 2019 at 08:57:09AM +, DJ Lucas via blfs-dev wrote:
>> On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev
> wrote:
>> 
>> >
>> >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.
>> 
>> That's not exactly correct. We are at the point where the majority
>use python3. We need to get rid of python2 build instructions for
>remaining modules that are not dependencies for something else using
>python2, sed/patch the remaining packages to explicitly use
>'/usr/bin/python2' or '/usr/bin/env python2' and then we are compliant
>with the PEP (84 IIRC) with a python->python3 symlink. The big thing is
>the "majority" of packages, though it was worded differently IIRC. Arch
>can really help here.
>> 
>> >
>> >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.
>> >
>> 
>> --DJ
>> 
>So, I looked at Arch and they are still using python2 for JS60.
>
>Fedora's build uses raw firefoxi68, I'm reluctant to try that.
>As I said in my original post: There is an issue for
>spidermonkey68 at gnome:
>  https://gitlab.gnome.org/GNOME/gjs/issues/270 which is
>apparently waiting for firefox 68.4.0 before it is ready.  That
>version of firefox should be released at the start of January.
>
>I suspect that when the new spidermonkey appears it _will_ need
>the python -> python3 symlink.
>
>In the meantime I found a patch at
>https://code.foxkit.us/adelie/packages/blob/f2b5773da19ab397fbe64fd32dacc383cfe4cd77/user/mozjs/python3.patch
>from Adelie linux, originally against 52.4.  A very strange patch, I
>could not get it to apply at all, so in the end I've spent some time
>manually running seds for some obvious things (e.g. remove from
>__future__) and then attempting to manually apply the other changes.
>Of course, some of the code has changed, and I'm sure not everything
>is right.
>
>What is most odd about the patch is that the first part has (original)
>and (refactored) marks for old and new files, but much later many
>other more conventional diffs have been appended, often several for
>the same file.
>
>But when I gave it a first go, with python symlinked to python3, the
>configure immediately failed:
>
>ken@plexi /tmp/mozjs-60.8.0/mozjs-build $../js/src/configure
>--prefix=/usr   \
>> --with-intl-api \
>> --with-system-zlib  \
>> --with-system-icu   \
>> --disable-jemalloc  \
>> --enable-readline
>  File "../js/src/../../configure.py", line 65
>print("Creating config.status", file=sys.stderr)

Sorry, I missed this. Yes this is python3 syntax so something is calling 
python2 explicitly.

--DJ


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


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

2019-12-15 Thread Ken Moffat via blfs-dev
On Fri, Dec 13, 2019 at 08:57:09AM +, DJ Lucas via blfs-dev wrote:
> On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev 
>  wrote:
> 
> >
> >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.
> 
> That's not exactly correct. We are at the point where the majority use 
> python3. We need to get rid of python2 build instructions for remaining 
> modules that are not dependencies for something else using python2, sed/patch 
> the remaining packages to explicitly use '/usr/bin/python2' or '/usr/bin/env 
> python2' and then we are compliant with the PEP (84 IIRC) with a 
> python->python3 symlink. The big thing is the "majority" of packages, though 
> it was worded differently IIRC. Arch can really help here.
> 
> >
> >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.
> >
> 
> --DJ
> 
So, I looked at Arch and they are still using python2 for JS60.

Fedora's build uses raw firefoxi68, I'm reluctant to try that.
As I said in my original post: There is an issue for
spidermonkey68 at gnome:
  https://gitlab.gnome.org/GNOME/gjs/issues/270 which is
apparently waiting for firefox 68.4.0 before it is ready.  That
version of firefox should be released at the start of January.

I suspect that when the new spidermonkey appears it _will_ need
the python -> python3 symlink.

In the meantime I found a patch at 
https://code.foxkit.us/adelie/packages/blob/f2b5773da19ab397fbe64fd32dacc383cfe4cd77/user/mozjs/python3.patch
from Adelie linux, originally against 52.4.  A very strange patch, I
could not get it to apply at all, so in the end I've spent some time
manually running seds for some obvious things (e.g. remove from
__future__) and then attempting to manually apply the other changes.
Of course, some of the code has changed, and I'm sure not everything
is right.

What is most odd about the patch is that the first part has (original)
and (refactored) marks for old and new files, but much later many
other more conventional diffs have been appended, often several for
the same file.

But when I gave it a first go, with python symlinked to python3, the
configure immediately failed:

ken@plexi /tmp/mozjs-60.8.0/mozjs-build $../js/src/configure --prefix=/usr  
 \
> --with-intl-api \
> --with-system-zlib  \
> --with-system-icu   \
> --disable-jemalloc  \
> --enable-readline
  File "../js/src/../../configure.py", line 65
print("Creating config.status", file=sys.stderr)
^
SyntaxError: invalid syntax

A quick look at https://docs.python.org/3/whatsnew/3.0.html suggests
that the syntax is correct.  So I'm giving up on this attempt to
find out which parts of my normal desktop still need python2.

ĸ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] Testing without python2 : dead halt at JS60.

2019-12-13 Thread DJ Lucas via blfs-dev
On December 12, 2019 11:30:59 PM CST, Ken Moffat via blfs-dev 
 wrote:

>
>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.

That's not exactly correct. We are at the point where the majority use python3. 
We need to get rid of python2 build instructions for remaining modules that are 
not dependencies for something else using python2, sed/patch the remaining 
packages to explicitly use '/usr/bin/python2' or '/usr/bin/env python2' and 
then we are compliant with the PEP (84 IIRC) with a python->python3 symlink. 
The big thing is the "majority" of packages, though it was worded differently 
IIRC. Arch can really help here.

>
>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.
>

--DJ


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page


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