cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | hacking on TLS is fun, way more fun than arguing over petty shit, turns out
<tumbleweed> we detecting some of the multiarch values from the processor is hard (e.g. armel vs armhf debian archs)
<tumbleweed> s/we//
<tumbleweed> so I can't even really put an if ladder in there to generate the right values
<tumbleweed> the simplest is to get it from the build environment. Either sys.implementation._multiarch from the caller python, or an environment variable / translation option. cpython uses a configure flag, for example
<tumbleweed> FWIW, the tuples are defined here: https://wiki.debian.org/Multiarch/Tuples
<tumbleweed> and as things are, I'd apply this patch in Debian: https://paste.debian.net/1214680/
<tumbleweed> but if it went back to using gcc --print-multiarch I wouldn't need to
<ceridwen> tumbleweed, That's what I figured about venv and pypy3 on Ubuntu/Debian. Thanks for confirming my suspicion! Nothing like requiring numpy for matplotlib.
<mattip> tumbleweed: I remeber 5f72d59b9aa1 giving the wrong value for some platform, I should have mentioned which in the commit message
<mattip> I will revert it, add your patch, and let's see what the buildbots come up with (the result will be in the tarball's _sysconfigdata__*.py file)
<LarstiQ> Does --print-multiarch also work for non-gcc environments?
<mattip> ahh, right, it fails on clang
<mattip> so will fail on darwin
<mattip> there is a patch for clang, but it is complicated http://reviews.llvm.org/D101400
<mattip> we cannot use sys.implementation._multiarch, since translation is usually done with pypy, and pypy < v7.3.6 does not have that value
<mattip> darwin is a non-issue, it uses something else from platform/darwin.py
<mattip> so I am going with the environment variable alternative and will document it
<tumbleweed> you can use sys.implementation._multiarch, with a fallback to something else
<tumbleweed> that's what I've been doing in pypy until now
<tumbleweed> my $DEB_HOST_MULTIARCH patch makes sense in the context of building debian packages, but not anywhere else
<mattip> IMO it's fine to add DEB_HOST_MULTIARCH though, better we patch it than you
<tumbleweed> it'd be nice if you'd carry this too, then: https://sources.debian.org/src/pypy3/7.3.6%7Erc2+dfsg-1/debian/patches/multiarch/
<mattip> sure
<mattip> is that for pytho2.7 as well?
<tumbleweed> yeah
<mattip> it seems not, sys.implemenation._multiarch is python3+
<tumbleweed> debian's python2 has sys.implemenation._multiarch too
<mattip> ohh. I guess it doesn't hurt to backport it
<tumbleweed> ah, no it's "sys._multiarch" on python 2
<tumbleweed> sys.implementation was the generalisation from upstream cpython
<mattip> hmm. So I will apply your patch to py3.7, py3.8
<mattip> and do sys._multiarch for 2.7
<tumbleweed> thanks, one less patch for me
<tumbleweed> you're applying the lib_pypy rearrangement to 3.8 only. I'm wondering if I should bite the bullet and do it for 2.7 and 3.x in Debian. It does tidy things up
<tumbleweed> I assume your motivation for 3.8-only was so virtualenv could handle it?
<tumbleweed> or is there a dependency on something in 3.8?
<mattip> It is a mess with setuptools which now vendors distutils which has its own command/install schema
<mattip> I guess I could have special cased via the pypy version number instead of the python version, but it seemed dangerous
<mattip> I don't want to break old versions
<tumbleweed> right
<mattip> maybe there are other tools that do funky stuff with the layout, it seemed safer to make a clean break with python3.8
<tumbleweed> I'll experiment if I find some time
<mattip> I guess it would be "safe" to backport the layout changes to 2.7, since anyway setuptools for 2.7 does not vendor distutils
<mattip> the changes to virtualenv should be version agnostic, they involve checking characteristics not versions
<mattip> my problem with virtualenv tests is that they compare themselves to venv, and venv was (is still) broken on the latest rc s
<tumbleweed> the code in pypy/module/imp/importing.py should probably be using multiarch, too
<tumbleweed> get_so_extension() I mean
<tumbleweed> I'm kind of suprised this works at all on non-amd64
<tumbleweed> this is the all-in-one patch for multiarch on 2.7 that I've been carrying: https://sources.debian.org/src/pypy/7.3.5+dfsg-3/debian/patches/multiarch/ - handles the tuple in C extensions, and exposes sys._multiarch + sysconfig.MULTIARCH
* tumbleweed -> bed
ceridwen has quit [Ping timeout: 246 seconds]
ceridwen has joined #pypy
blackpingus has joined #pypy
AxTheB has joined #pypy
Julian has joined #pypy
jryans has quit [Write error: Connection reset by peer]
the_drow has quit [Write error: Connection reset by peer]
graingert[m] has quit [Write error: Connection reset by peer]
ambv has quit [Read error: Connection reset by peer]
jryans has joined #pypy
ambv has joined #pypy
graingert[m] has joined #pypy
the_drow has joined #pypy
<mattip> tumbleweed: that patch is a bit much to swallow this late in the release cycle, I created an issue for the next release
<LarstiQ> I'm assuming tumbleweed is fine with that, the patch has been in the .debs for a long time, upstreaming it is nice but not mandatory
<LarstiQ> Date: Sat, 7 Oct 2017 09:38:58 +0200
<LarstiQ> yup
Julian has quit [Ping timeout: 245 seconds]
<mattip> +1
Julian has joined #pypy
<tumbleweed> LarstiQ: exactly
<tumbleweed> I should have caught this when the multiarch consumption code landed in 6.0.0
Julian has quit [Ping timeout: 245 seconds]
Julian has joined #pypy
<mattip> an interesting experiment to remove the python GIL
<mattip> costs about 10% of single threaded performance, if I am reading correctly
<marmoute> SimonSapin: on est sortie du mini-sprint si tu veux papotter en vrai fans 5-10 minute
<marmoute> grmlm, wrong channel
Julian has quit [Ping timeout: 245 seconds]
Julian has joined #pypy
Julian has quit [Ping timeout: 245 seconds]
Julian has joined #pypy
Julian has quit [Ping timeout: 252 seconds]
Julian has joined #pypy
Julian has quit [Ping timeout: 245 seconds]
Julian has joined #pypy
Julian has quit [Ping timeout: 265 seconds]
Julian has joined #pypy
Julian has quit [Client Quit]
<tumbleweed> mattip: thanks for landing that. I'd say we could back out DEB_HOST_MULTIARCH, I can set PYPY_MULTIARCH in my build environment, from it
<tumbleweed> I would also suggest something like https://paste.debian.net/1214784/ - that I'm just testing now
mattip has quit [Ping timeout: 245 seconds]
mattip has joined #pypy
shodan45 has quit [Ping timeout: 252 seconds]
shodan45 has joined #pypy
<tumbleweed> mattip: instead of config.guess, copying this would probably make more sense: https://github.com/python/cpython/blob/b108db63e02797a795840152b82cab9792fd3ed2/configure.ac#L723-L868
<tumbleweed> gcc tuples != multiarch tuples
Julian has joined #pypy
blackpingus has quit [Quit: Konversation terminated!]
Julian has quit [Quit: leaving]