Further discussion in #debian-python:
21:57 < p1otr> from what I see new pypy still doesn't privide all these config
vars I use
21:58 < p1otr> except for MULTIARCH
21:58 < tumbleweed> such as?
21:59 < p1otr> "SOABI", "MULTIARCH", "INCLUDEPY", "LIBPL", "LDLIBRARY"
21:59 < tumbleweed> those are new in Py3k, right?
21:59 < tumbleweed> at least, I think SOABI si. Dunno about the others
22:00 < p1otr> no, but f.e. last one is used only in cmake
22:00 < tumbleweed> dh_pypy runs under /usr/bin/python3, so is exposing that
config even
usedful?
22:00 < p1otr> so only first two are important
22:00 < tumbleweed> right, it looks like pypy really should provide SOABI
22:01 < tumbleweed> they did version tagged .so files, upstream
22:03 < p1otr> so which solution do you prefer? I'm OK with both of them, can
implement the
second one tomorrow evening
22:03 < p1otr> and do an upload of dh-python, I already have quite a but of new
stuff
22:03 < tumbleweed> I'm guessing the second one is the right approach
22:03 < tumbleweed> it makes new pypy releases a whole lot easier
22:04 < tumbleweed> but means we have to do some work
22:04 < tumbleweed> what do you need, to do it? SOABI?
22:05 < p1otr> SOABI is probably not required, but it would be great if you
could provide it
(and send patch upstream)
22:05 < tumbleweed> yeah, I'm looking at that now
22:06 < p1otr> I usually get these config vars from distutils.sysconfig, but in
case of pypy
it's taken from sysconfig
22:07 < p1otr> ah, right, distutils is used only in older cpython versions
22:08 < p1otr> so sysconfig.get_config_vars("SOABI", "MULTIARCH", "INCLUDEPY",
"LIBPL",
"LDLIBRARY") is what I use
22:10 < p1otr> (and it doesn't matter in which language is dh_pypy written, I
Popen pypy)
22:12 < tumbleweed> right
22:29 < tumbleweed> p1otr: I don't think pypy will ever provide a LIBPL
22:29 < tumbleweed> it's currently not built shared, so having no LDLIBRARY is
sane
22:30 < tumbleweed> INCLUDEPY is a bit of a mess :/
22:32 < tumbleweed> p1otr: and you think pypy-26 is a reasonable virtual
package?
22:33 < p1otr> it is, I think I'd use pypy-abi-26, though
22:34 < tumbleweed> yeah, that's clearer
22:34 < tumbleweed> but it means we have to mangle the abi :P
22:34 < tumbleweed> still, it's a simple mangle
22:35 < p1otr> time for bed here, I'll take care of it tomorrow (late, I play
football on
Mondays)
22:35 < tumbleweed> thanks
And #pypy:
07:18 < tumbleweed> arigato: https://bugs.debian.org/803689 is this sane?
07:19 < arigato> hi tumbleweed and all
07:19 < tumbleweed> (option 2, that is)
07:19 < tumbleweed> arigato: hi :)
07:20 < arigato> I tried to change that in order to fix the name of the
CPython-module .so
files
07:21 < arigato> it's likely that it will change again
07:21 < tumbleweed> the change applies to cffi .so files too
07:21 < tumbleweed> which is fine for Debian
07:21 < arigato> yes, so that they have the same name
07:22 < tumbleweed> am I right that pypy's bytecode hasn't changed in ages? I
seem to recall
that when I first started packaging pypy, the bytecode was
still in flux
07:22 < arigato> in the future though, maybe they should have different names
and contain a
tag that gets changed only when there is really an
incompatiblity
07:22 < tumbleweed> it seems that's the way you've gone now
07:22 < arigato> not yet? they have the same name
07:23 < arigato> I mean the same extension, ".pypy-26.so"
07:23 < tumbleweed> well, I mean pypy 4.0.0 uses the pypy-26 tag
07:23 < arigato> I mean that both CPython C API modules and CFFI modules use
".pypy-26.so"
07:23 < tumbleweed> yes
07:23 < arigato> but we will probably change that in the future
07:23 < tumbleweed> oh, "they should have different names" means different from
each other
07:23 < arigato> yes
07:23 < tumbleweed> yeah, probably
07:24 < arigato> and indeed there is also the bytecode .pyc version
07:24 < arigato> the bytecode format tends to not change any more, right
07:25 < tumbleweed> yeah, I think that was an issue as cPython was changing,
but in 2.x
that's basically over
07:25 < arigato> we added a few custom bytecodes long ago
07:25 < tumbleweed> yeah
07:26 < tumbleweed> ok, so I'm going to keep debian pypy using .pypy-26.so
(well
.pypy-26-x86_64-linux-gnu.so or similar) and do
.pypy-26.pyc too
07:26 < tumbleweed> then revisit this when we need to
07:27 < arigato> if you have some suggestion for upstream, they are welcome
07:27 < arigato> I think that cffi can be kept backward- and forward-compatible
07:27 < tumbleweed> so, it seems the only thing right now, is to expose SOABI
in sysconfig
07:28 < arigato> .pyc too
07:28 < arigato> but maybe cpyext will see big changes
07:29 < tumbleweed> I've tried to incorporate cffi's version ranges into Debian
package
dependencies, but can't quite yet (waiting for a feature in
dpkg)
07:31 < tumbleweed> so I can't use the min and max versions yet, but I can just
use VERSION
(a strict dependency) and that works quite neatly
07:31 < tumbleweed> we could expose that version in the filename, but then I
guess importing
searching gets painful
07:34 < tumbleweed> and now, bed for me :)
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
