definitely does want to create the virtualenv 2.53.18.3

will compare this virtualenv.py against .2's

oh duh meant 2.53.19

lots of diff

oneforall2 Bug 1909061

...

It seems that the package that caused my issue was python3-setuptools.

After I have uninstalled python3-setuptools, build ran without problems, I just need to use

MACH_USE_SYSTEM_PYTHON=1, without which I had problems building zstandard

MACH_USE_SYSTEM_PYTHON=1 i have that

what version of python3-setuptools I have 75.1.0

oneforall2 python setuptools need to be deinstalled for now. Might be fixed in the latest tree but can't test

frg_Away: we have no real control which python is being executed

i literally cannot get the thing to execute with a specific python by any other means than running it with python

nsITobin this is poython setuptools not python

yeah but i can't run with anything but python3.6 because that is the designated system python

the result of calling python3

on here

its gonna be different for every system

he is likely getting conflicts with running it as a shell command is ALWAYS gonna run virtualenv OR "python3"

no env just whatever python3 is and PYTHON env var is ignore despite the fact that it has a bash stub header

In Rocky 8 sudo alternatives --remove python3 /usr/bin/python3

Not sure why it defaults to 3.6?

yeah well the build system should TRY from newest to oldest to find a working version of python it knows how to use.. rocky defaults to 3.6 because 3.6 IS the system python version needed for dnf mozilla patches assume you either have the correct system python or gonna be using the artifact version

As fas as I know support for 3.6 is gone from mozilla

when it was 2.7 it tried various bin names to find its self that should have been expanded when it was obvious every python 3 version is incompatible forwards and backwards with every other python 3 version

I updated 2.53 xyesterday with patvches stating 3.7

using 3.11 it fails for zstandard

Worked last time under Windows. Need to check

frg_Away yeah tried that and still fails internal was 49.x

oneforall2: use older python

remove python 3.11

i dunno

any chance a symlink along with PATH can affect this, or it's immune to such suggestions too?

i think the build system is fighting with its self

i am certainly fighting with it in ways I shouldn't be

e.g. mkdir $HOME/python-link && cd python-link && ln -s /usr/bin/python3runthis python3 , then PATH="$HOME/python-link:$PATH"

that's just plain unacceptable

need to read the bug, because this is quite bittle if the build system or python try to guess by themselves where the "right" python is

something in virtualenv.py breaks it cause 2.53.18.2 has no problem compiling

the build system needs eithe reverted back to its original 56 state and adapted properly or it needs to be replaced with a newer complete mozilla build system

because first and foremost the build system is needed to do anything else

I only have 1 python installed

and its the wrong python good job

well as said its seamonkey broke now since that last one compiles with 3.11.10

the build fixes in 2.53.19 are a bit half baked. 2.53.20 should be better. Not fully baked but ok. Will check 3.11 compile

python-zstandard-0.22.0 noticed it wanted old wheel etc so compiles the old waywith setup

unshare -n python3 setup.py install --root=$PKG

build --wheel etc needs a version bump :)

I meaqn in the zstandard src

nsITobin the current 2.53 source works for me in Rocky 8 with its python 3.11

frg_Away 253-nightly-source.tar.xz ?

yes

same problem

I used mach mach-create-mach-environment. Will retry with system pathon set to 1

Sorry can't reproduce in Rocky 8 with pytho 3.11.9

^python

added seed packages: pip==20.3.1, setuptools==51.0.0, wheel==0.36.1 notice its not using the system wheel setuptools pip

not finding --with-system-pip etc

As Myckel stated in the bug should eventually be fixed when we move mores stuff in. Linux ins unfortunately a pain with every distribution different.

not a fan of python :)

whats the url for this bug?

tobin: to paraphrase a trending DNS mantra out there: It is not the python version\nThere is no way it's the python version\nIt was the python version

oneforall2: probably bugzil.la/1909061

hmm notice too the 253.18.2 is using setup.py that does make a diff

mastodon.social/@jwz/113199661915847625 your daily Primordial Mozilla drama

I'll check once social.sdf.org de-500s itself