On Fri, Dec 23, 2011 at 1:44 PM, Stefano Rivera <stefa...@debian.org> wrote: > Hi debian-python (2011.11.28_22:25:18_+0200) >> I'm interested in this, and happy to help. > > ... so, I've spent some time on this, and have an incomplete package to > show for it: http://anonscm.debian.org/gitweb/?p=users/stefanor/pypy.git > Got lots of family things happening atm, so haven't done anything in the > last couple of days, and won't do much more in the next few, so I > thought now would be a good time for a status report. > Anyone feel like collaborating on the remaining issues? > > == High level == > Imported most relevant stdlib patches from Debian's python2.7 package. > (Meh, multiple copies of the stdlib is ugly, but unavoidable) > Patches that I haven't imported or looked at thoroughly yet: > statvfs-f_flag-constants.diff, distutils-sysconfig.diff > > I added PEP3147 support, largely based on Barry's initial PEP3147 patch. > It seems to work, but isn't very well tested yet. > I also made __file__ refer to the source file, which predated PEP3147. > This may cause some things to break, needs more investigation. > > A few failing tests remaining. Most of the failing tests are due to my > modifications, and I haven't fixed the tests yet. > > virtualenv is currently broken, details below. > > == Patches applied == > The patches all have DEP3 headers, so I don't think I have to say too > much here... > > == Packing stuff == > I've got a basic working package build. The rules file isn't pretty, but > it does the job... > > The package splits the stdlib into an architecture-independant package, > which makes byte-compilation of the stdlib a little more trick, but I > think I've got that working reliably. > > The package is xz compressed. If you can build it, you can compress it > :) > > Copyright file is incomplete (all the stdlib modules with odd licences > haven't been mentioned). > > PyPy includes the constants from the shared libraries it links against. > I don't *think* this is a major problem (although an unnecessary space > waste), but it was enough to make lintian scream blue murder. > > PyPy doesn't handle prefix quite the same way as cpython. It finds its > standard library by looking up the directory hierarchy from its binary, > with a usual install layout like this: > . > ├── bin > │ └── pypy > ├── include > │ └── ... > ├── lib_pypy > │ └── ... > ├── lib-python > │ ├── 2.7 > │ │ └── ... > │ └── modified-2.7 > │ └── ... > └── site-packages > > You'll notice that this matches the source layout, and so pypy's > sysconfig scheme allows it to run installed or from a build directory, > with the same scheme. > I have a hacky /usr prefix patch, and a dist-packages patch but they > break virtualenv. > Virtualenv attempts to run a copy of the python inside the virtualenv. > It then isn't in /usr and so can't find its modules. > > I'm thinking a better solution here is to *always* look in /usr unless > an environment variable (that we'll have set at build time, for the > tests) is present. > > > I'm building some binaries now (build takes 3 hours or so, bootstrapping > from cpython), I can post a link when they are done. > > SR > > -- > Stefano Rivera > http://tumbleweed.org.za/ > H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127
Hi Stefano. Wouldn't looking always at /usr first break checkout overriding system version? That would be very unfortunate unless this is only for the debian-modified version. PS. Thanks for doing that! Cheers, fijal -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cak5idxsjyy+2qfsdzcs2oit6db8qmahzfptvg0wn_yclgm-...@mail.gmail.com
