00:09:15 <oneforall2> definitely does want to create the virtualenv 2.53.18.3
00:10:44 <oneforall2> will compare this  virtualenv.py against .2's
00:15:39 <oneforall2> oh duh meant 2.53.19
00:19:59 <oneforall2> lots of diff
10:57:50 <frg_Away> oneforall2 Bug 1909061
10:58:20 <frg_Away> ...
10:58:22 <frg_Away> It seems that the package that caused my issue was python3-setuptools.
10:58:23 <frg_Away> After I have uninstalled python3-setuptools, build ran without problems, I just need to use
10:58:25 <frg_Away> MACH_USE_SYSTEM_PYTHON=1, without which I had problems building zstandard
13:10:16 <oneforall2> MACH_USE_SYSTEM_PYTHON=1 i have that
13:28:42 <oneforall2> what version of python3-setuptools  I have 75.1.0
15:22:57 <frg_Away> oneforall2 python setuptools need to be deinstalled for now. Might be fixed in the latest tree but can't test
15:27:35 <nsITobin> frg_Away: we have no real control which python is being executed
15:28:00 <nsITobin> i literally cannot get the thing to execute with a specific python by any other means than running it with python
15:28:02 <frg_Away> nsITobin this is poython setuptools not python
15:28:35 <nsITobin> yeah but i can't run with anything but python3.6 because that is the designated system python
15:28:55 <nsITobin> the result of calling python3
15:28:56 <nsITobin> on here
15:29:02 <nsITobin> its gonna be different for every system
15:29:37 <nsITobin> he is likely getting conflicts with running it as a shell command is ALWAYS gonna run virtualenv OR "python3"
15:30:00 <nsITobin> no env just whatever python3 is and PYTHON env var is ignore despite the fact that it has a bash stub header
15:38:06 <frg_Away> In Rocky 8 sudo alternatives --remove python3 /usr/bin/python3
15:38:15 <frg_Away> Not sure why it defaults to 3.6?
15:41:25 <nsITobin> 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
15:42:18 <frg_Away> As fas as I know support for 3.6 is gone from mozilla
15:42:21 <nsITobin> 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
15:42:51 <frg_Away> I updated 2.53 xyesterday with patvches stating 3.7
15:43:37 <nsITobin> using 3.11 it fails for zstandard
15:44:29 <frg_Away> Worked last time under Windows. Need to check
15:45:00 <oneforall2> frg_Away yeah tried that and still fails internal was 49.x
15:45:09 <nsITobin> oneforall2: use older python
15:45:15 <nsITobin> remove python 3.11
15:45:19 <nsITobin> i dunno
15:45:50 <njsg> any chance a symlink along with PATH can affect this, or it's immune to such suggestions too?
15:46:50 <nsITobin> i think the build system is fighting with its self
15:47:03 <nsITobin> i am certainly fighting with it in ways I shouldn't be
15:47:11 <njsg> e.g. mkdir $HOME/python-link && cd python-link && ln -s /usr/bin/python3runthis python3 , then PATH="$HOME/python-link:$PATH"
15:47:34 <nsITobin> that's just plain unacceptable
15:47:34 <njsg> 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
15:48:36 <oneforall2> something in virtualenv.py breaks it  cause 2.53.18.2 has no problem compiling
15:49:24 <nsITobin> 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
15:49:39 <nsITobin> because first and foremost the build system is needed to do anything else
15:50:53 <oneforall2> I only have 1 python installed
15:51:05 <nsITobin> and its the wrong python good job
15:51:52 <oneforall2> well as said its seamonkey broke now since that last one compiles  with 3.11.10
16:06:30 <frg_Away> 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
16:24:26 <oneforall2> python-zstandard-0.22.0 noticed it wanted old wheel etc so compiles the old waywith setup
16:24:56 <oneforall2> unshare -n python3 setup.py install --root=$PKG
16:26:00 <oneforall2> build --wheel  etc needs a version bump :)
16:35:50 <oneforall2> I meaqn in the zstandard src
16:49:05 <frg_Away> nsITobin the current 2.53 source works for me in Rocky 8 with its python 3.11
16:54:03 <oneforall2> frg_Away  253-nightly-source.tar.xz ?
16:54:49 <frg_Away> yes
16:54:58 <oneforall2> same problem
16:56:29 <frg_Away> I used mach mach-create-mach-environment. Will retry with system pathon set to 1
17:05:35 <frg_Away> Sorry can't reproduce in Rocky 8 with pytho 3.11.9
17:05:45 <frg_Away> ^python
17:16:39 <oneforall2> added seed packages: pip==20.3.1, setuptools==51.0.0, wheel==0.36.1  notice its not using the system wheel setuptools pip
17:17:21 <oneforall2> not finding --with-system-pip etc
17:18:51 <frg_Away> 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.
17:27:29 <oneforall2> not a fan of python  :)
17:28:52 <oneforall2> whats the url for this bug?
17:30:11 <njsg> 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
17:31:05 <njsg> oneforall2: probably http://bugzil.la/1909061
20:47:52 <oneforall2> hmm notice too the 253.18.2 is using setup.py that does make a diff
21:37:15 <tomman> https://mastodon.social/@jwz/113199661915847625 your daily Primordial Mozilla drama
21:49:15 <njsg> I'll check once social.sdf.org de-500s itself