04:27 <mattip> I thought extra_tests were meant to run on cpython and pypy,

04:28 <mattip> but py3.7-errormsg-improvements adds "from traceback import _levenshtein_distance, _compute_suggestion_attribute_error"

04:28 <mattip> which doesn't exist on CPython

04:28 <mattip> and was added directly to the stdlib

04:29 <mattip> I think the import should be conditional, and the code should be moved into a lib_pypy pypy-specific module

04:32 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7704 [mattip: force build, py3.8-vectorcall]

04:32 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8718 [mattip: force build, py3.8-vectorcall]

05:15 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7704 [mattip: force build, py3.8-vectorcall]

05:27 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8718 [mattip: force build, py3.8-vectorcall]

06:13 <arigato> mattip: re issue 3483 (_sysconfigdata): I think the idea is that it's officially impossible to do what the OP is trying to do, but he managed with a hack that he describes, which is that the _sysconfigdata.py file is just a plain dictionary and so if he runs the wrong pypy3 (from x86_64) on the right _sysconfigdata.py (aarch64) then he gets the right answer (from aarch64)

06:16 <arigato> or I mean, this hack works on CPython but not on pypy3

06:25 <cfbolz> mattip: that's cpython's fault, they added features to the C-implementation of traceback.py, but didn't keep traceback.py in sync

06:28 <cfbolz> but I am fine with fixing tests to not crash on cpython, of course

06:40 <arigato> mattip: the docker used by the OP is called messense/manylinux2014-cross:aarch64 so I guess it's not a x86_64 docker

08:39 <mattip> arigato: I guess we could create and ship the various _sysconfigdata* files they are expecting,

08:39 <mattip> but I want to see exactly what they are, and how they are built

09:00 <bbot2> Started: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/3306 [py3.7]

09:17 <mattip> arigato: inside that docker image there are executables for aarch64, and _sysconfigdata_m_linux_aarch64-linux-gnu.py files with static values for each version of cpython

09:17 <mattip> we create a single _sysconfigdata.py with dynamic values that are filled in by the interpreter when the file is imported

09:18 <mattip> so I guess we could convert the dynamic values into a platform-specific _sysconfigdata_linux* file when packaging pypy?

10:30 <bbot2> Success: http://buildbot.pypy.org/builders/jit-benchmark-linux-x86-64/builds/3306 [py3.7]

14:04 <tumbleweed> that sysconfigdata setup sounds like it came from debian multiarch. I see it made it into upstream cpython

14:04 <tumbleweed> so, yeah, would be nice to have in pypy too, to be able to co-install multiple architectures

14:04 <tumbleweed> (although I'd have to do some work to make it possible)

14:42 <mattip> cpython on macOS, what is the value of sys.implementation? Does it have a "_multiarch" field?

14:44 <mattip> that becomes part of the `_sysconfigdata_*` file name, see "sysconfig._get_sysconfigdata_name()"

15:00 <mattip> anyone with macOS that can help out?

15:55 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7705 [mattip: force build, multiarch]

15:55 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/271 [mattip: force build, multiarch]

15:55 <bbot2> Started: http://buildbot.pypy.org/builders/own-win-x86-64/builds/326 [mattip: force build, multiarch]

15:55 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8719 [mattip: force build, multiarch]

16:00 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7705 [mattip: force build, multiarch]

16:43 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8719 [mattip: force build, multiarch]

16:56 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7706 [mattip: force build, multiarch]

17:02 <mattip> it seems the gcc in the manylinux images prints nothing for "gcc --print-multiarch"

17:03 <mattip> where the one in ubuntu prints "x86_64-linux-gnu"

17:03 <mattip> I guess it will be easier to just hardcode the values

17:45 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-64/builds/271 [mattip: force build, multiarch]

17:57 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7706 [mattip: force build, multiarch]

18:48 <bbot2> Failure: http://buildbot.pypy.org/builders/own-win-x86-64/builds/326 [mattip: force build, multiarch]

19:05 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7707 [mattip: force build, multiarch]

19:05 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8720 [mattip: force build, multiarch]

19:15 <arigato> we now officially have the #cffi channel. I'm pointing there (and also here as a second choice) in the cffi docs

19:28 <cfbolz> mattip: if I add a number of ifdefs I can get testcapimodule to compile

20:03 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8720 [mattip: force build, multiarch]

20:13 <bbot2> Started: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8721 [Carl Friedrich Bolz-Tereick: force build, py3.8-vectorcall]

20:20 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7707 [mattip: force build, multiarch]

20:20 <bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7708 [Carl Friedrich Bolz-Tereick: force build, py3.8-vectorcall]

21:04 <bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7708 [Carl Friedrich Bolz-Tereick: force build, py3.8-vectorcall]

21:10 <bbot2> Failure: http://buildbot.pypy.org/builders/own-linux-x86-64/builds/8721 [Carl Friedrich Bolz-Tereick: force build, py3.8-vectorcall]